Documento de análisis y especificación Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil

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

Download "Documento de análisis y especificación Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil"

Transcripción

1 Documento de análisis y especificación Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil 05/04/2014 Ingeniería de Sistemas - PUJ Juan Darío Murcia Torres 0

2 Tabla de contenido Qué es?... 4 Cómo va? (Historial de Cambios)... 5 Documento de análisis y especificación Ingeniería de Requerimientos Qué es un requerimiento? Tipos de Requerimientos El Proceso Problemática e introducción a las Metodologías Ágiles Metodologías Ágiles Scrum XP (extreme Programming) Kanban SEMAT (Software Engineering Method And Theory) Los Alfas Principios del Kernel de SEMAT El Kernel es Accionable El Kernel es Extensible El Kernel es Práctico Qué se está haciendo hoy en día? Bibliografía

3 Tabla de ilustraciones Ilustración 1. Clasificación de Requerimientos... 8 Ilustración 2. Relación de los requerimientos con otros procesos de un proyecto (Tomado de [3]).. 10 Ilustración 3. Scrum (Tomado de [11]) Ilustración 4. XP. (Tomado de 20 Ilustración 5. Tablero Kanban. (Tomado de [19]) Ilustración 6. "Cosas con las que siempre trabajamos". (Tomado de [22]) Ilustración 7. "Cosas que siempre hacemos". (Tomado de [22]) Ilustración 8. Alfa - Oportunidad. (Tomado de [23]) Ilustración 9. Estados Alfa - Oportunidad. (Tomado de [23]) Ilustración 10. Alfa - Oportunidad; Estado - Identificado. (Tomado de [23]) Ilustración 11. Alfa - Oportunidad; Estado - Solución necesaria. (Tomado de [23]) Ilustración 12. Alfa - Oportunidad; Estado - Valor establecido. (Tomado de [23]) Ilustración 13. Alfa - Oportunidad; Estado - Viable. (Tomado de [23]) Ilustración 14. Alfa - Oportunidad; Estado - Dirigido. (Tomado de [23]) Ilustración 15. Alfa - Oportunidad; Estado - Beneficio acumulado. (Tomado de [23]) Ilustración 16. Alfa - Stakeholders. (Tomado de [23]) Ilustración 17. Estados Alfa - Stakeholders. (Tomado de [23]) Ilustración 18. Alfa - Stakeholders; Estado - Reconocido. (Tomado de [23]) Ilustración 19. Alfa - Stakeholders; Estado - Representado. (Tomado de [23]) Ilustración 20. Alfa - Stakeholders; Estado - Involucrado. (Tomado de [23]) Ilustración 21. Alfa - Stakeholders; Estado - De acuerdo. (Tomado de [23]) Ilustración 22. Alfa - Stakeholders; Estado - Satisfecho por el despliegue. (Tomado de [23]) Ilustración 23. Alfa - Stakeholders; Estado - Satisfecho en uso. (Tomado de [23]) Ilustración 24. Alfa Requerimientos Ilustración 25. Estados Alfa Requerimientos. (Tomado de [23]) Ilustración 26. Alfa - Requerimientos; Estado - Concebido. (Tomado de [23]) Ilustración 27. Alfa - Requerimientos; Estado - Delimitado. (Tomado de [23]) Ilustración 28. Alfa - Requerimientos; Estado - Coherente. (Tomado de [23]) Ilustración 29. Alfa - Requerimientos; Estado - Aceptable. (Tomado de [23]) Ilustración 30. Alfa - Requerimientos; Estado - Direccionado. (Tomado de [23]) Ilustración 31. Alfa - Requerimientos; Estado - Cumplido. (Tomado de [23]) Ilustración 32. Alfa - Sistema de software. (Tomado de [23]) Ilustración 33. Estados Alfa - Sistema de software. (Tomado de [23]) Ilustración 34. Alfa - Sistema de software; Estado - Arquitectura seleccionada. (Tomado de [23]) Ilustración 35. Alfa - Sistema de software; Estado - Demostrable. (Tomado de [23]) Ilustración 36. Alfa - Sistema de software; Estado - Usable. (Tomado de [23]) Ilustración 37. Alfa - Sistema de software; Estado - Listo. (Tomado de [23]) Ilustración 38. Alfa - Sistema de software; Estado - Operacional. (Tomado de [23]) Ilustración 39. Alfa - Sistema de software; Estado - Retirado. (Tomado de [23]) Ilustración 40. Alfa - Equipo. (Tomado de [23]) Ilustración 41. Estados Alfa - Equipo. (Tomado de [23]) Ilustración 42. Alfa - Equipo; Estado - Seeded. (Tomado de [23]) Ilustración 43. Alfa - Equipo; Estado - Formado. (Tomado de [23]) Ilustración 44. Alfa - Equipo; Estado - Colaborando. (Tomado de [23])

4 Ilustración 45. Alfa - Equipo; Estado - Ejecutando. (Tomado de [23]) Ilustración 46. Alfa - Equipo; Estado - Suspendido. (Tomado de [23]) Ilustración 47. Alfa - Trabajo. (Tomado de [23]) Ilustración 48. Estado Alfa - Trabajo. (Tomado de [23]) Ilustración 49. Alfa - Trabajo; Estado - Iniciado. (Tomado de [23]) Ilustración 50. Alfa - Trabajo; Estado - Preparado. (Tomado de [23]) Ilustración 51. Alfa - Trabajo; Estado - Comenzado. (Tomado de [23]) Ilustración 52. Alfa - Trabajo; Estado - Bajo control. (Tomado de [23]) Ilustración 53. Alfa - Trabajo; Estado - Culminado. (Tomado de [23]) Ilustración 54. Alfa Trabajo; Estado Cerrado. (Tomado de [23]) Ilustración 55. Alfa - Forma de trabajar. (Tomado de [23]) Ilustración 56. Estados Alfa - Forma de trabajar. (Tomado de [23]) Ilustración 57. Alfa Forma de trabajar; Estado Principios. (Tomado de [23]) Ilustración 58. Alfa Forma de trabajar; Estado Bases establecidas. (Tomado de [23]) Ilustración 59. Alfa Forma de trabajar; Estado En uso. (Tomado de [23]) Ilustración 60. Alfa Forma de trabajar; Estado En su lugar. (Tomado de [23]) Ilustración 61. Alfa Forma de trabajar; Estado Trabajando bien. (Tomado de [23]) Ilustración 62. Alfa Forma de trabajar; Estado Retirado. (Tomado de [23])

5 Qué es? Este documento es una síntesis de los diferentes escritos, artículos, libros y contenido académico en general que ha sido consultado por el estudiante para el trabajo de grado Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil. Este es el principal entregable generado durante la fase de Análisis y Especificación, y tiene como objetivo fundamental servir como base de conocimiento para la fase de Integración de Componentes. 4

6 Cómo va? (Historial de Cambios) A continuación se muestran a modo de comentarios, las adiciones y modificaciones del documento. Fecha Sección Comentario 03/02/2014 Todas Creación del documento. Se tomó como base la información recopilada durante vacaciones. 07/02/2014 1, 2 Refinación de ideas e inclusión de comentarios del SWEBOKv3. 11/02/2014 1, 2 Inclusión de ideas del Software Requirements de Wiegers. 12/02/2014 1, 2 Inclusión de otras ideas de Wiegers. 15/02/2014 1, 2, 3 Corrección de contenido. 20/02/ Adición de la sección 4. Qué se está haciendo hoy en día? 21/02/2014 Todo Revisión total de documento, y determinación temas que hacen falta. 24/02/ Corrección de algunos de los comentarios hechos por el Ingeniero Miguel. 26/02/ Corrección de otros comentarios hechos por el Ingeniero Miguel. 04/03/ Creación sección 1.2. Tipos de Requerimientos. 05/03/ Refinación de ideas. 06/03/ Creación sección 1.3. El Proceso. 07/03/ , Creación de las secciones Obtención de requerimientos; y Análisis de requerimientos. 09/03/ , Creación de las secciones Especificación de requerimientos; y Validación de requerimientos. 10/03/ , 1.3 Creación de la sección Gestión de requerimientos. 12/03/ Revisión de toda la sección 1.3. El Proceso. 14/03/2014 4, 5 Cambio de la Sección 4. Qué se está haciendo hoy en día? Por la sección 5. Qué se está haciendo hoy en día? E inclusión de la nueva sección 4. SEMAT (Software Engineering Method And Theory). 15/03/ Inclusión de nuevas ideas 16/03/ Inclusión de nuevas ideas 17/03/ Creación de la sección 3.3. Kanvan 19/03/ Refinamiento SEMAT 21/03/ Refinamiento SEMAT (Detallando los Alfas) 5

7 22/03/ Mejor detalle del Kernel (Inclusión de imágenes), y mejor especificación de los Alfas 23/03/ Especificación de Alfas faltantes. 29/03/2014 Todas Limpieza de comentarios, aceptación de cambios y revisión general. Especificación estados del Alfa Oportunidad. 30/03/ Especificación de estados del alfa Stakeholders 31/03/ y Especificación de estados del alfa Requerimientos 01/04/ , y Especificación de estados de los alfas Equipo, Trabajo y Forma de trabajo. 04/04/ Especificación de Kanban. 05/04/2014 Todas Revisión final 6

8 Documento de análisis y especificación 1. Ingeniería de Requerimientos 1.1. Qué es un requerimiento? Se conoce como requerimiento o requisito a una petición o declaración realizada por una o más personas, el cual traduce o expresa una necesidad. En el mundo del software, los requerimientos son usados para desarrollar un sistema que cumpla con dichas necesidades, teniendo en cuenta las condiciones y restricciones que estas conlleven [1] Tipos de Requerimientos Los requerimientos son un complejo conjunto de combinaciones que se genera por la interacción entre los actores de los diferentes niveles en una organización [2]. En un proyecto de software, se pueden encontrar varios tipos de estos. A nivel general, se podrían clasificar en dos grandes clases, los requerimientos del producto [2], y a un nivel más de la organización, se encuentran los requerimientos de negocio [3]. En cuanto a los requerimientos de negocio, básicamente se pueden encontrar las reglas de negocio, y los requerimientos/restricciones de procesos. Este tipo de requerimientos afecta al producto en cuanto a que lo restringe de acuerdo a los objetivos de la organización y al negocio en sí mismo [3]. Acá se tienen en cuenta las diferentes reglamentaciones de acuerdo a la naturaleza de cada organización, y por tal motivo, esto también encierra diferentes estándares, pólizas y normas de regulación en general [3]. Este tipo de requerimientos son establecidos por la organización, y en algunos casos (como en los requerimientos de proceso) los clientes o terceros [2]. Los requerimientos del producto abarcan más tipos de requerimientos, y se refieren básicamente a las necesidades o restricciones del software desarrollado [2]. En esta categoría se encuentran contenidos los requerimientos de usuario, y los requerimientos del sistema, y estos a su vez se dividen en muchos más requerimientos. Todos los requerimientos de esta categoría son proporcionados en su gran mayoría por los Stakeholders (usuarios, clientes, y cualquier otra persona u organización afectada por el software a desarrollar), sin embargo, no se debe descartar la posibilidad de que la organización o terceros también proporcionen información de valor. A continuación se muestra un diagrama con la clasificación que he realizado, luego de leer diferentes autores, y cabe aclarar que estos son sólo algunos de los tipos de requerimientos más usados, sin embargo dependiendo de cada autor esta clasificación puede variar. 7

9 Requerimientos Req. Negocio Req. Producto Req. Proceso Reglas de Negocio Req. Usuario Req. Sistema Req. Software Req. Hardware Req. Funcionales Req. No Funcionales Ilustración 1. Clasificación de Requerimientos Pero cuáles son las características de cada tipo de requerimiento?, a continuación se explica brevemente cada uno: Requerimientos de negocio Se refieren a un conjunto de información de alto nivel que, en su totalidad, describe una necesidad del negocio, y que lleva a uno o más proyectos a ofrecer una solución y los resultados operativos deseados [3]. Dichas soluciones o resultados se podrían presentar por medio del desarrollo de un producto por parte de la misma organización, o acordar con algún tercero para que este lo haga. [2] Requerimientos de proceso Este tipo de requerimientos son proporcionados como necesidades durante todo el proceso del proyecto, y se refieren al cómo hacer las cosas. Se pueden ver como restricciones en cuanto a las metodologías usadas, con el fin de que estas no vallan en contra a los objetivos de la organización, ni de los clientes. Pueden ser proporcionados por las directivas, los clientes, e inclusive algunos terceros. [2] Reglas de negocio Se refieren a todo tipo de normas, estándares y reglamentación en general (tanto internas de la organización, como externas a esta), que limitan al negocio. [3] Requerimientos de producto Este tipo de requerimientos abarca a todas aquellas necesidades que sean tenidas en cuenta para el producto o sistema en general [2]. Dichos requerimientos suelen ser proporcionados por los usuarios y los clientes, sin embargo, también podrían estar derivados de algunos requerimientos de negocio [3] Requerimientos de usuario Describen a las necesidades del negocio, desde el punto de vista de las personas y los resultados que estas quieren obtener del nuevo producto. [4] 8

10 Requerimientos del sistema Este tipo de requerimientos agrupan a todos los relacionados con las capacidades del sistema, e incluyen las capacidades que deben ser proporcionadas por el software, el hardware y las personas [3] Requerimientos de hardware Se refieren a todas necesidades, características y restricciones de dispositivos y componentes físicos que sean necesarios para desarrollar y soportar la solución de software generada Requerimientos de software Este tipo de requerimientos tiene en cuenta más que al sistema en general, al conjunto de características y funcionalidades que se espera, tenga el software desarrollado Requerimientos funcionales Se pueden ver como una descripción del comportamiento que el sistema deberá mostrar bajo condiciones específicas [3]. Este comportamiento se entiende como la funcionalidad que el software va a ejecutar [2] Requerimientos no funcionales Este tipo de requerimientos son más que todo, restricciones que limitan al sistema, y que describen características que este debe mostrar. En algunos casos, son llamados atributos de calidad, y generan otro tipo de requerimientos como lo son, requerimientos de rendimiento, de mantenibilidad, de safety, de confiabilidad, de seguridad, y de interoperabilidad, entre otros. [2] Como se mencionó anteriormente, estos tipos de requerimientos son sólo algunos de los que se pueden encontrar en los textos, y que dependiendo el autor, podría variar el nombre y definición acá proporcionado. Una vez mencionado lo anterior, es pertinente decir, que los requerimientos no solo son proporcionados por los usuarios del sistema, los dueños de este, terceros o en general, los diferentes Stakeholders, ya que existen algunas propiedades emergentes que van saliendo a la luz a medida que avanza el proceso de Ingeniería de Requerimientos. Estas propiedades, también son consideradas como requerimientos, y por su naturaleza, no pueden ser trazables a componentes en específico, ya que estas dependen de cómo interactúen todos los componentes de software. [2] 1.3. El Proceso El término de Ingeniería de Requerimientos (IR) tal y como se conoce actualmente comenzó a usarse luego de una publicación de la IEEE Computer Society en 1990 [5], y corresponde a un proceso sistemático para el descubrimiento, desarrollo, trazabilidad, análisis, clasificación, comunicación y gestión de requerimientos, el cual define un sistema en niveles sucesivos de abstracción [6]. Desde entonces dicho proceso es considerado como una parte fundamental de cualquier proceso de desarrollo de software, sin embargo el detalle en cada una de sus etapas depende del tipo de metodología de desarrollo a implementar. Algunos autores consideran que el término de Ingeniería de Requerimientos está mal usado, y que en vez de este, debería ser el de Requerimientos de Software, sin embargo para este documento, y el resto de los entregables, se va a continuar usando el término de Ingeniería de Requerimientos para referirse a dicho proceso. Como ya se ha mencionado anteriormente, la IR es sólo un proceso dentro de todo proyecto de desarrollo de software. Este proceso busca fundamentalmente facilitar las tareas que soporten los demás procesos de negocio al interior de una organización [2]; y como todo proceso, sirve de entrada y salida para muchos otros. A medida que los Ingenieros de software adquieren 9

11 conocimiento y habilidad en la gestión de estos proyectos, se observan mayores capacidades para relacionar procesos de todo el proyecto u organización. Ilustración 2. Relación de los requerimientos con otros procesos de un proyecto (Tomado de [3]) Obtención de requerimientos Esto es lo primero en cualquier proceso de IR, y abarca todo lo relacionado con el descubrimiento de estos, y el cómo el ingeniero de software los recolecta. Acá se realizan actividades tales como entrevistas, creación de escenarios, reuniones y talleres, análisis de documentos y prototipos, observación de actividades e historias de usuarios, entre otras, con el fin de abarcar todo el entorno y obtener el mayor detalle posible acerca del nuevo software a desarrollar. [2] [3] En la obtención de requerimientos, así como en todo el proceso de IR y el Ciclo de Vida del Desarrollo de Software, el principio fundamental es la comunicación efectiva entre los Stakeholders (los cuales también son definidos con detalle en esta fase), y el equipo desarrollador [2]. Para facilitar la comunicación, se hace necesario tener modelos consistentes en los diferentes niveles de abstracción, y esto se logra primero que todo, clasificando e identificando a los individuos que mejor conocen los procesos que se verán afectados por el nuevo software, esto con el fin entender sus tareas y los objetivos de negocio con las que estas se alinean. También es fundamental aprender del entorno en el cual el nuevo producto será usado, con el fin de aterrizar los requerimientos obtenidos. [3] Para que esta fase tenga éxito, lo fundamental es tener un completo entendimiento de la problemática que se piensa solucionar, y esto implica conocer detalladamente: los objetivos de alto nivel de la organización, los Stakeholders, las reglas del negocio, y los ambientes operacional y organizacional Análisis de requerimientos Al igual que las otras fases del proceso de IR, esta parte es fundamental para el proyecto e implica un alto grado de compromiso y detalle por parte de los analistas de requerimientos. Los resultados de esta fase podrían definir en gran parte el éxito o fracaso del proyecto. 10

12 El análisis de requerimientos se ocupa principalmente de detectar y resolver los conflictos entre los requerimientos obtenidos en la etapa anterior, de igual forma descubrir los límites del software y cómo este podría interactuar con los ambientes organizacional y operacional. De igual forma, en esta fase, son generados los requerimientos de software con base a los requerimientos del sistema. [2] Para poder realizar lo mencionado anteriormente, primero que todo se debe analizar la información recolectada en la etapa de obtención de requerimientos, y detallar el objetivo de las tareas de los usuarios, esto con el fin de clasificar los requerimientos de acuerdo a su naturaleza, es decir, si son propiamente del negocio, o si son del sistema. Los requerimientos de negocio, aportarán información importante y un contexto a los del sistema y posteriormente a los de software [3]. Seguido de esto, se toman los requerimientos de alto nivel y se descomponen con un apropiado nivel de detalle [3]. Estos sirven para completar los requerimientos del sistema. Se detallan y clasifican los requerimientos de software, y con estos los funcionales, no funcionales y los demás requerimientos que hacen falta por clasificar [2] [3]. Una vez realizada dicha clasificación de requerimientos, se asigna una prioridad a cada requerimiento teniendo en cuenta los diferentes factores que pueden afectar al proyecto [2], estos son los costos, el tiempo, las probabilidades de cambio de estos durante el ciclo de vida del proyecto e inclusive los objetivos del negocio. Después de la priorización, viene el modelado. En esta parte la idea es entender mejor la situación en la que un problema dado ocurre, y la solución presentada. Para esto, se pueden usar diagramas de casos de uso, modelos de flujo de datos, modelos de estado, modelos basados en objetivos, interacciones entre usuarios, modelos de objetos y modelos de datos, entre otros [2]. Para realizar el modelado, hay que tener en cuenta factores como la naturaleza del problema, la experticia del ingeniero de software y las peticiones de cada usuario. En esta fase también es importante tener en cuenta la arquitectura del sistema, ya que los nuevos requerimientos deben satisfacer dicha arquitectura, y en algunas ocasiones se hace necesario modificarla para que se acople correctamente. Esta ya es la parte final de la fase, y una vez que se tiene en cuenta la priorización y la arquitectura, se procede a negociar los requerimientos con el usuario, ya que no siempre lo que este desea es posible Especificación de requerimientos La especificación de requerimientos consiste en, una vez establecidos los requerimientos que realmente tienen valor para el cliente y para el negocio, traducir estos a requerimientos formalmente constituidos [3]. Estos requerimientos formarán parte de un documento que podrá ser revisado, evaluado y aprobado de manera sistemática por parte del equipo de desarrollo y del cliente. Dependiendo de la complejidad de cada sistema, podrán ser generados hasta tres documentos diferentes en esta fase: Documento de Definición del Sistema, Especificación de Requerimientos del Sistema, y Especificación de Requerimientos de Software (SRS); para el caso de proyectos de software simples, sólo es necesario el SRS. [2] En el SRS se establecen los requerimientos negociados entre el cliente y la parte que va a desarrollar el software, de esta manera, se llega a un consenso sobre lo que el software debe y no debe hacer. Algo importante en la construcción de este documento, es el formalismo a la hora de escribir cada requerimiento, ya que entre más detallado y formal se escriba, permitirá reducir la probabilidad de errores en la especificación y con esto, tener que rediseñar el sistema en un futuro; también esto permitirá determinar con mayor precisión los costos, riesgos y el calendario. Este documento será la 11

13 base sobre la cual trabajarán los ingenieros en un futuro, y es sobre este que verificarán y validarán los planes. [2] Validación de requerimientos Una vez terminada la especificación, viene la validación de requerimientos. Acá básicamente se determina por parte de los desarrolladores, si los requerimientos especificados anteriormente realmente ayudarán a dar solución a la problemática, y si satisfacen los objetivos del negocio [3]. Para lograr lo anteriormente propuesto, es necesario asegurarse que los ingenieros de software hayan comprendido correctamente los requerimientos, y esto es posible realizando un conjunto de actividades en compañía de los diferentes Stakeholders a fin de aprobar o desaprobar lo que hasta el momento se ha especificado [2]. La primera actividad que se debe realizar es revisar los documentos generados en la fase anterior, con el fin de encontrar errores, suposiciones incorrectas y falta de claridad, esto último generado usualmente por requerimientos poco entendibles, inconsistentes e incompletos. Adicional a esto, se pueden crear prototipos que permitan una mejor interpretación de las suposiciones de los ingenieros de software, lo malo con estos, es que pueden ser costosos de desarrollar. Finalmente, se crean pruebas de aceptación, para determinar qué requerimientos después de todo no son válidos, y no deben ser tenidos en cuenta. Todo esto se debe hacer a fin de corregir posibles problemas antes de aceptarlos y continuar con el proceso de desarrollo Gestión de requerimientos La gestión de requerimientos no se ejecuta en algún momento en específico del proyecto, sino que abarca todo lo referente a la planeación, monitorización del progreso y gestión de cambios durante todo el ciclo de vida de este [6]. Tiene como principio el que los requerimientos de un proyecto de software pueden cambiar en cualquier momento [1], y teniendo en cuenta esto, establece procedimientos para la definición, control y publicación de requerimientos de línea base [1]. Existen muchos tipos de proyectos, y la gestión, es algo común en todos, sin embargo, dependiendo el tipo de proyecto, esta podría generar mejores resultados si se efectúa de una u otra forma. La planeación debería ser gestionada de acuerdo a los resultados generados en cada etapa. Dichos resultados tendrían que ser aprobados antes de realizar cualquier actividad por el experto del negocio, a fin de establecer si las soluciones propuestas van acorde a las necesidades de los usuarios, y si estas no van en contra de los objetivos del negocio. En el caso de proyectos de desarrollo de software, esta aprobación se da con la aceptación del documento SRS. [6] La monitorización del proyecto se realiza por medio de la recolección de métricas. Estas consisten en un conjunto de información obtenida a medida que avanzan las diferentes actividades propuestas. Existen diferentes tipos de métricas, como por ejemplo, las de calidad y rendimiento, las cuales por sí solas no dirán mucha información a menos que sean comparadas con los planes determinados anteriormente. Una vez que las métricas son comparadas con los planes, se podrá determinar el progreso del proyecto, y así, tomar decisiones más acertadas respecto a este. [6] La gestión de cambios usa como principal herramienta el versionamiento de los diferentes documentos y artefactos generados durante cada actividad. Acá es donde se definen las características y los artefactos de línea base que se generarán durante el proyecto, por lo que es necesario, siempre al principio de este, establecer las diferentes reglas (nombre, historial de cambios ) que se tendrán en cuenta a la hora de crear dichos artefactos, esto con el fin de lograr una fácil trazabilidad y manejo de versiones. En el caso de que en un futuro haya la necesidad de volver a un estado anterior en algún documento o versión de software, el proceso anterior hará que 12

14 no sea traumático, ni genere muchos inconvenientes. Un mal manejo de versiones y de gestión de cambios en general, podría verse traducido en tener que hacer re-planeación de alguna de las etapas establecidas desde el inicio del proyecto. [1] [6] Se debe tener cuidado con los excesos y/o fallas en la gestión, ya que esto podría traer sobrecostos, retrasos en el calendario, errores de diseño, clientes insatisfechos, y hasta la cancelación del proyecto [1]. 13

15 2. Problemática e introducción a las Metodologías Ágiles Los principales inconvenientes que surgen en un proyecto, con relación a los requerimientos, se dan por la importancia que tienen los Stakeholders, en cuanto a que al ser ellos los conocedores/afectados del sistema, son los encargados de proporcionar los requerimientos del mismo, los cuales se pueden observar como complejas combinaciones de diferentes niveles de la organización, y que se conectan con las características del ambiente en el que este va a operar [2]. Por esto, las personas son consideradas indispensables, pero muchas veces no cuentan con la paciencia o tiempo para participar en las actividades que implican este proceso [3]. Este tipo de problemas son más comunes en metodologías tradicionales, en las cuales los ingenieros deben valerse de diferentes técnicas durante la etapa de obtención de requerimientos, con el fin de que la información obtenida sea relevante y suficiente para continuar con las siguientes etapas y desarrollar el sistema que el cliente realmente espera. Caso contrario a las metodologías ágiles, en las cuales el cliente y/o usuario está presente durante la mayor parte del proceso de desarrollo, haciendo que el producto (o subproductos) final generado, esté más acorde a los requerimientos del usuario. Las metodologías ágiles fueron introducidas formalmente desde mitad de los años 90s con la implementación de los métodos más usados (RUP, Scrum y XP), pero fue hasta 2001 cuando se conocieron formalmente como metodologías ágiles con la publicación del Manifiesto Ágil [7] [8]. Teniendo en cuenta que una IR formal gasta tiempo, y con la necesidad de rápidos cambios en el software, las metodologías ágiles han obtenido gran popularidad debido a los enormes cambios tecnológicos de los últimos tiempos, y a las facilidades y oportunidades que ellos han generado en cuanto a comunicaciones, mercados y condiciones económicas. Estos cambios obligan a los sistemas nuevos y a los ya existentes a responder de manera competitiva a las diferentes demandas que se proponen a diario [9], por tal motivo, se espera que el software desarrollado hoy en día atienda dichas necesidades. En este tipo de metodologías, se considera que es mejor dedicar más esfuerzos y recursos a la elaboración propia del producto, y no sólo a las fases iniciales del proyecto. Teniendo en cuenta esto, se asume que la simplicidad en las tareas es un factor fundamental a la hora de desarrollar software [8]. Parte de esta simplicidad consiste en la reducción de la formalidad que implica el proceso de IR, dedicando más esfuerzos a la creación de software funcional por medio de una fuerte comunicación con el cliente, sin embargo, al no ser este tipo de metodologías lo suficientemente formal, algunos elementos no se encuentran claramente separados e identificados, provocando dificultades en el futuro cuando se necesite algún producto propio de estos procesos (problemas con la trazabilidad de requerimientos y/o subproductos generados) [10]. Con el paso del tiempo se han observado algunos cambios y tendencias en la forma de desarrollar software, y esto no solo incluye metodologías de desarrollo, sino también todo lo referente a la IR. Algunas cosas han cambiado y otras han continuado igual, como es el caso de la falta de relevancia que se le da al proceso de IR aun cuando es conocido por todos los Ingenieros de Software que éste hace parte fundamental en cualquier proyecto de desarrollo y el típico problema de todo proyecto que se da porque los Stakeholders ignoran lo que realmente quieren [3]. Por otro lado, el avance tecnológico de los últimos tiempos, unificado a la necesidad de que éste sea cada vez más rápido, y la búsqueda por cumplir las diferentes expectativas referentes a las comunicaciones y a los nuevos mercados, hace que el nuevo software a desarrollar deba ser más 14

16 competitivo. Teniendo en cuenta este contexto de continuo cambio, se han observado diferentes tendencias que cada vez son más fuertes. Algunas de dichas tendencias se podrían relacionar con el fortalecimiento de las metodologías ágiles por medio de un uso más amplio de la IR en proyectos de desarrollo, lo que genera una mayor y más fácil integración en proyectos futuros [3]. Adicional a esto, se han desarrollado herramientas que ayudan la gestión de requerimientos y de algunos de los componentes propuestos durante el proceso de IR como el Product Backlog (en el caso de Scrum) [3]. Dichas herramientas deberían poder usarse acorde al principal referente que se tiene hoy en día en cuanto a requerimientos, el estándar ISO/IEC/IEEE [1], el cual no garantiza por completo que lo que se esté haciendo se encuentre bien, pero por lo menos sirve de guía a los Ingenieros y Stakeholders en este importante proceso. 15

17 3. Metodologías Ágiles 3.1. Scrum Considerado como el método ágil más popular, Scrum es un framework iterativo e incremental para proyectos y productos o desarrollo de aplicaciones [11] que se desarrolla en ciclos de trabajo llamados Sprints. Scrum no es un proceso o técnica para construir productos; en lugar de eso es un marco de trabajo dentro del cual se pueden emplear varias técnicas y procesos [12]. El marco de trabajo de Scrum consiste en el equipo Scrum, roles, eventos, artefactos y reglas asociadas, los cuales son mostrados como interacción en la Ilustración 3. Ilustración 3. Scrum (Tomado de [11]) Scrum se encuentra basado en controles de procesos empíricos, de modo que se asegura que el conocimiento precede de la experiencia y se puedan tomar decisiones más acertadas. Existen tres pilares que soportan la implementación del proceso empírico, estos son [12]: Transparencia, que implica que los aspectos significativos deben ser visibles para los responsables del resultado, lo que se logra por medio de la estandarización de dichos aspectos. Inspección constante y moderada de los artefactos de Scrum, de manera que sin interferir en el trabajo, se logren identificar variaciones en estos. Adaptación de procesos o artefactos de manera oportuna, de tal forma que no se presenten mayores desviaciones en el rumbo del proyecto Scrum Team El equipo Scrum consta de 3 roles: Dueño del Producto (Product Owner): Es el único responsable (persona) de gestionar el Product Backlog, y sus decisiones deben ser respetadas por la organización. Esta gestión incluye [12]: 16

18 o o o o o Expresar claramente los elementos del Product Backlog. Ordenar los elementos del Product Backlog para alcanzar los objetivos y misiones de la mejor manera posible. Optimizar el valor del trabajo desempeñado por El Equipo. Asegurar que el Product Backlog sea visible, transparente y claro para todos, y que muestre en lo que El Equipo trabajará a continuación. Asegurar que el equipo de desarrollo entiende los elementos del Product Backlog al nivel necesario. El Equipo (The Team): Los equipos son auto-gestionados, auto-organizados y multifuncionales, y son los responsables de encontrar la manera de convertir el Product Backlog en un incremento de funcionalidad al interior de cada iteración gestionando su propio trabajo a ser realizado. Los miembros del equipo son responsables del éxito de cada iteración y del proyecto en conjunto [13]. El tamaño óptimo de El Equipo debe estar entre 3 y 9 personas, que es un grupo lo suficientemente pequeño como para permanecer ágil, y lo suficientemente grande como para completar una cantidad de trabajo significativa. Scrum Master: No es el administrador del equipo ni del proyecto. El Scrum Master es el responsable de asegurar que Scrum se aplique y sea entendido de la manera adecuada y está al servicio del Scrum Team para garantizar que éste trabaje ajustado a la teoría, prácticas y reglas de Scrum. De igual forma ayuda a externos al Scrum Team a entender qué interacciones con el equipo pueden ser de ayuda y cuáles no, además de maximizar el valor creado por el Scrum Team por medio de modificaciones de dichas interacciones. [12] Eventos de Scrum En Scrum, todo el trabajo se realiza en Sprints (son el corazón de Scrum), los cuales contienen a todos los eventos de Scrum. Dichos eventos son bloques de tiempo, de manera que tienen una duración máxima. Una vez comienza un Sprint, su duración es fija y no puede acortarse o alargarse. Los demás eventos pueden terminarse una vez alcancen el objetivo del evento, asegurando que se emplee la cantidad de tiempo apropiada y sin desperdicio en el proceso. [12]. Cada Sprint debe tener una duración de 2 a 4 semanas (no más, no menos); tiempo en el cual se crean incrementos en el producto. Estos incrementos implican un producto utilizable y potencialmente desplegable. No puede haber miembros de un mismo Equipo Scrum en Sprints simultáneos, por lo que cada iteración inicia con la finalización de la anterior. En un Sprint no se realizan cambios que afecten al Sprint Goal u Objetivo del Sprint, de manera que los objetivos de calidad no se disminuyen. El alcance puede ser clarificado y renegociado entre el Product Owner y El Equipo a medida que se obtiene nuevo conocimiento [12]. Un Sprint podría ser cancelado únicamente por el Product Owner, y sólo si el Sprint Goal quedara obsoleto por cambios en el negocio, mercado o tecnología. Debido a la corta duración de las iteraciones, es raro cancelar Sprints, sin embargo si esto llegase a suceder, se entra a una etapa de evaluación por parte del Product Owner para determinar si hay trabajo potencialmente entregable, y se vuelven a estimar los elementos no terminados del Product Backlog. Una cancelación genera costos y traumas para el proyecto. [12]. A continuación se enuncian y se da una breve explicación de los eventos en Scrum: 17

19 Objetivo del Sprint (Sprint Goal): Es propuesto durante el Sprint Planning Meeting, y corresponde a la meta establecida para el Sprint. Proporciona una guía al Equipo acerca del por qué se está realizando dicho incremento. Los eventos al interior de los Sprints que Scrum proporciona para la inspección y adaptación tanto de los procesos usados, como de los artefactos producidos, son los siguientes cuatro [12]: Reunión de planificación del Sprint (Sprint Planning Meeting): Es la reunión inicial de cada Sprint, en la que se planifica el trabajo a realizar durante la iteración. Esta reunión es vigilada por el Scrum Master para asegurar que se haga de la manera adecuada y no debería durar más de 8 horas. Durante esta reunión se responden principalmente las siguientes preguntas: o o Qué puede entregarse en el incremento resultante del Sprint que comienza? Cómo se conseguirá hacer el trabajo necesario para entregar el incremento? Scrum diario (Daily Scrum): Reunión diaria de 15 minutos de duración en la que todos los miembros del Equipo deben estar presentes, con el fin de crear un plan para las siguientes 24 horas. Durante esta reunión se pretende que cada miembro del Equipo responda las siguientes preguntas: o o o Qué hice ayer que ayudó al Equipo a cumplir con el Sprint Goal? Qué haré hoy para ayudar al Equipo a cumplir con el Sprint Goal? Veo algún impedimento que evite que El Equipo o yo logremos el Sprint Goal? Revisión del Sprint (Sprint Review): Al terminar el Sprint, El Equipo dedica 4 horas o menos (dependiendo la duración del Sprint) para presentar al Product Owner lo realizado durante la iteración [13], con el fin de actualizar el Product Backlog y definir los elementos para el siguiente Sprint. El Sprint Review corresponde a una reunión informal y no de seguimiento, en la que pueden además participar los interesados que colaboraron al Equipo. Adicional a la presentación ante el Product Owner, se busca fomentar la colaboración entre El Equipo. Al igual que en el Sprint Planning Meeting, es deber del Scrum Master asegurarse que la reunión se haga de la manera adecuada. Retrospectiva del Sprint (Sprint Retrospective): Reunión de duración no mayor a 3 horas (dependiendo la duración del Sprint), en la que se tiene como propósito: o o o Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas. Identificar y ordenar los elementos más importantes que salieron bien, y las posibles mejoras. Crear un plan para implementar las mejoras a la forma en que el equipo Scrum desempeña su trabajo. Las mejoras propuestas deben ser validadas junto al Scrum Master, garantizando que se implementen dentro del framework de Scrum. 18

20 Artefactos Scrum Scrum define los siguientes artefactos con el fin de proporcionar transparencia y oportunidades para la inspección y adaptación [12]: Product Backlog: Contiene una lista de los requerimientos (características) del sistema o producto a ser desarrollado por el proyecto, junto a una descripción, ordenación, estimación y valor para cada ítem. El Product Owner es el responsable del contenido y su priorización y disponibilidad. El Product Backlog es dinámico; la gestión cambia constantemente para identificar lo que el producto necesita para ser apropiado, competitivo y útil [13]. Un proceso continuo durante todo el proyecto, es el de refinamiento del Product Backlog, que consiste en añadir detalle, estimaciones y orden a los elementos de la lista en su interior. Durante este proceso son examinados y revisados los elementos de la lista. Este refinamiento es posible, gracias al avance logrado con el cumplimiento de los Sprint Goals [12]. Sprint Backlog: Especifica el trabajo o lista de tareas que El Equipo define seleccionar del Product Backlog para un Sprint específico. En el Sprint Backlog se hace visible todo el trabajo que El Equipo considera como necesario para lograr el Sprint Goal. A medida que el trabajo se completa, se va actualizando la estimación del trabajo restante XP (extreme Programming) Metodología ágil de desarrollo propuesta formalmente por primera vez en Extreme Programming Explained [14], donde fue definida como un ligero, eficiente, de bajo riesgo, predecible, científico y divertido método para desarrollar software. Se diferencia según su autor Kent Beck por [15]: Su anticipada, concreta, e inmediata reacción de ciclos internos. Su enfoque de planeación incremental, el cual rápidamente surge con un plan general que se espera, evolucione a través del ciclo de vida del proyecto. Su capacidad de programar con flexibilidad la implementación de la funcionalidad, en respuesta a las cambiantes necesidades del negocio. Su dependencia de pruebas automatizadas escritas por clientes y programadores para monitorear el progreso del desarrollo, permitiendo al sistema evolucionar y capturar los defectos tempranamente. Su dependencia de la comunicación oral, pruebas, y código fuente para comunicar la estructura y propósito del sistema. Su dependencia de un proceso de diseño evolutivo que dura lo que dura el sistema. Su dependencia de la estrecha colaboración de los programadores con conocimientos comunes. Su dependencia de las prácticas que funcionan tanto con los instintos de corto plazo de los programadores y como de los intereses a largo plazo del proyecto. 19

21 Como se mencionó anteriormente, XP es considerado una metodología ágil para el desarrollo de software, por lo que suele ser complementario a Scrum (que es menos técnico y más enfocado hacia la gestión de proyectos) [9]. En la primera versión de XP, este era definido con 4 valores, 15 principios básicos y 20 prácticas, y se indicaba de manera muy estricta que para poder ser XP, se tenían que cumplir las 20 prácticas propuestas, sin embargo, desde su segunda edición, pasó a ser definido por medio de 5 valores, 14 principios, 13 prácticas primarias y 11 de corolario. [16] Valores XP A continuación se enuncian los valores en los que se basa extreme Programming [16]: Comunicación: Para evitar errores y problemas es necesario que los miembros del equipo se comuniquen de manera adecuada y constante. Simplicidad: Aunque requiere experiencia, y trabajo duro, es necesario hacer las cosas lo suficientemente simples como para no afectar la comunicación en el equipo y reducir la cantidad de código. Retroalimentación: Es un componente importante de comunicación, y fortalece a esta en cuanto se realice de manera apropiada. Esto contribuye a la simplicidad. Coraje: Valores como la comunicación, simplicidad y retroalimentación permitirán hacer frente con valentía, incluso a grandes cambios en requerimientos y refactorización sustancial del sistema. Respeto: Para lograr lo anterior, los miembros del equipo de desarrollo deben ser respetuosos con ellos y sus contribuciones. Ilustración 4. XP. (Tomado de 20

22 Principios XP Los principios en los que se basa XP son [16]: Humanidad: El software es desarrollado por personas, por lo que es necesario saber estimar los objetivos y necesidades de las personas, pero esto debe hacerse de manera que no se afecte la productividad. Económico: Si se produce software, este debería generar valor para el negocio. Dos aspectos económicos son claves para XP: el valor presente y el valor de las opciones. El primer aspecto sugiere que entre más temprano se desarrolle el software, va a ser más rentable para el negocio. El segundo indica que se pueden aplazar las inversiones en diseño hasta que sean obvias. Beneficio mutuo: Cualquier actividad debería beneficiar a todas las personas y a la organización, sin embargo esto es difícil de realizar debido a que por lo general las cosas que son beneficiosas para unos, no siempre lo son para otros. Auto-semejanza: Se debe tener la capacidad de reutilizar soluciones similares en diferentes contextos. Mejora: La perfección no existe, sin embargo se debe luchar constantemente para alcanzarla, esto es por medio de iteraciones en el desarrollo que proporcionen funcionalidades y calidad por medio de la retroalimentación. Diversidad: Los equipos deberían incluir personas con diferentes conocimientos, cualidades y caracteres, ayudando a proporcionar una mayor cantidad de soluciones. Reflexión: Los equipos efectivos no deberían hacer el trabajo porque sí. Es necesario que se pregunten el cómo están trabajando, y el por qué lo están haciendo de esa manera. Flujo: Las prácticas de XP sugieren un continuo flujo de actividades y no una secuencia de diferentes fases que libere software hasta el final. Oportunidad: Los problemas deben ser vistos como oportunidades de mejora. Siempre se van a presentar inconvenientes y es allí donde se hace necesario aprender, y generar retroalimentación. Redundancia: Problemas críticos y dificultades deberían poder ser resueltos de diferentes maneras. Esto asegura que al tener muchas posibilidades, si alguna falla, otras podrían prevenir un desastre. Fracaso: No se debe relacionar con un aspecto negativo, siempre que se pueda aprender de ellos. Calidad: La calidad siempre debe ser máxima, y no se debe confundir con el perfeccionismo. Pequeños pasos: Es peligroso aplicar en un solo paso grandes cambios realizados en un largo periodo de tiempo. Por lo que se ve necesario proceder paso a paso y de manera iterativa, asegurando que no se produzcan daños por aplicar cambios en la dirección equivocada. Responsabilidad aceptada: La responsabilidad solo puede ser aceptada. Es fácil ordenar a los desarrolladores haga esto o haga aquello, pero esto no es trabajar. 21

23 Prácticas XP Existen dos grupos de prácticas, las primarias y las de corolario. Beck propone que estas prácticas deben aplicarse completamente para obtener los máximos beneficios de XP. Aunque no se proporciona una clasificación oficial por parte del autor, las prácticas se podrían clasificar de la siguiente manera [16]: Prácticas primarias o Planeación y análisis de requerimientos Historias: Las funcionalidades del sistema son descritas usando historias, que son pequeñas descripciones visibles al cliente, de lo que puede hacer el sistema. Ciclo semanal: El desarrollo de software es realizado por semana. Al comienzo de cada semana se realiza una reunión donde las historias de desarrollo son seleccionadas por el cliente. Ciclo trimestral: En escalas de tiempo mayor, el desarrollo es planeado por trimestre. Esto incluye reflexiones del equipo, del proyecto y del progreso. Flojo: Evite hacer promesas que no pueda cumplir. Todo plan incluye tareas que podrán ser ignoradas. o Factores humanos y equipo Sentarse juntos: Para maximizar la comunicación, los equipos de desarrollo deberían trabajar en espacios abiertos, permitiendo alojar al equipo completo. Todo el equipo: El equipo debe estar compuesto por miembros que cumplan con todas las características y necesidades del proyecto. Espacio de trabajo informativo: El espacio de trabajo debería ser provisto con carteleras y otras cosas que proporcionen información del estado del proyecto y las tareas a ser realizadas. Trabajo energizado: Los desarrolladores deben ser productivos y estar atentos a su trabajo. Programación en pares: El código debe ser escrito por dos programadores en una misma máquina. o Diseño Diseño incremental: El diseño es indispensable para obtener buen código, y se sugiere que sea realizado de manera incremental durante la codificación. Programación de primero prueba : Antes de escribir el código, se hace necesario desarrollar las pruebas que lo verificarán. o Codificación de software y liberación 22

24 Compilación de 10 minutos: El sistema debería ser compilado y todas las pruebas deberían ser finalizadas en 10 minutos, en orden de que se ejecute y se pueda obtener retroalimentación. Integración continua: Los desarrolladores deberían integrar cambios cada 2 horas. Prácticas de corolario o Planeación y análisis de requerimientos Participación real del cliente: Las personas que se vean afectadas por el sistema, deberían ser parte del equipo y pueden contribuir a la planificación semestral o trimestral. Despliegue incremental: Cuando se reemplacen los restos de un sistema, es necesario reemplazar primero algunas funcionalidades, y gradualmente todo el sistema. Contrato de alcance negociado: Los contratos para el desarrollo de software, deberían tener de manera fija elementos como tiempos, costos y calidad, pero el alcance del proyecto debería ser negociado durante su realización. Pago por uso: El cliente suele pagar por versión de software, esto crea un conflicto entre el proveedor y el cliente debido a que este último quiere grandes cambios en menos versiones, lo que está completamente por fuera de XP. o Factores humanos y equipo Continuidad del equipo: Los equipos de desarrollo deberían ser los mismos para todos los proyectos. Contracción de equipos: Como el equipo se vuelve más capaz y productivo, es necesario mantener la carga, pero reducir gradualmente al equipo, enviando a los miembros libres a formar nuevos equipos. o Diseño Análisis de origen de causa: Siempre que se encuentre un defecto, hay que eliminarlo junto a sus causas. Esto ayudará a que no vuelva a suceder. o Codificación de software y liberación Código y pruebas: Sólo el código y las pruebas son artefactos permanentes y deben ser preservados. Los otros documentos pueden ser generados con base a estos dos artefactos. Código compartido: Cualquiera en el equipo de desarrollo debe ser capaz de cambiar cualquier parte del sistema. Código base único: Esto es solo una versión oficial del sistema. 23

25 Despliegue diario: Cada noche se debe poner software en producción. Es costoso tener brechas entre versiones de software lanzadas y las de producción personal de los desarrolladores Kanban Este no es un método para el desarrollo de software, sino para la gestión de proyectos; y aunque poco a poco se ha ido adaptando a los proyectos referentes al software (gracias a David J. Anderson quien adaptó el método original al desarrollo de software [17], y a Microsoft quien lo usó por primera vez), fue pensado inicialmente para ayudar en los procesos de producción de Toyota, usando técnicas JIT (Just-In-Time). Esta metodología de gestión, tiene como base fundamental los principios Lean, y presenta su practicidad en el uso de tarjetas para modelar actividades. Precisamente por esto el nombre de Kanban, ya que es una palabra del japonés, que etimológicamente hablando traduce Kan visual y ban tarjeta. Estas tarjetas se usan comúnmente para identificar necesidades de material en la cadena de producción. [18] [19] Kanban sugiere sistemas de producción altamente efectivos, regidos por algunos principios que reflejan que su origen viene de Lean y que dependiendo el autor, pueden variar, pero aun así, mantienen la esencia. Los principios Kanban son [19]: Calidad garantizada: todo se debe hacer lo mejor posible desde el comienzo, y no debe esperarse a que haya problemas para solucionarlos. En Kanban no hay margen de error, y es preferible demorarse un poco más realizando las actividades y asegurar así que estas son de calidad, a tener que retrasar el proyecto por problemas generados al no hacer las cosas bien. Reducción de desperdicio: este principio propone que no hay que desgastarse haciendo cosas que generan poco o nada de valor para el proyecto. Sólo se debe trabajar en las cosas que sean necesarias para asegurar que se hagan bien y con el tiempo necesario. Mejora continua: todo el proyecto es un continuo aprendizaje. Kanban es un sistema de mejora y permite la aplicación de los conocimientos adquiridos durante el proyecto. Esto con el fin de mejorar dinámicamente el desarrollo del mismo. Flexibilidad: al igual que metodologías como Scrum, Kanban posee un Backlog donde se encuentran los ítems a desarrollar, sin embargo, Kanban no se limita al trabajo por Sprints, ya que su naturaleza consiste en el trabajo continuo. En este caso el Backlog no es gestionado por los Sprints, ya que las actividades y tareas se van priorizando de acuerdo a la necesidad. 24

26 Ilustración 5. Tablero Kanban. (Tomado de [19]) Algo fundamental en este método es el uso de un tablero de tareas para mejorar el flujo de trabajo durante el proyecto. Algunos autores proponen diferentes formas o pasos para acomodar la estrategia a ser usada con el tablero, y que más se acomode al proyecto. Algunos de estos pasos consisten [19]: 1. Definir el flujo de trabajo del proyecto. a. Crear un tablero visible por todos los miembros del equipo. b. Cada columna del tablero consiste en un estado concreto del flujo de tareas. c. Deben existir tantas columnas como estados tenga que pasar una actividad. d. Las actividades se gestionan de manera continua y no por Sprints. e. Las nuevas tareas son acumuladas en la sección inicial y priorizadas luego por el cliente. 2. Visualizar las fases del ciclo de producción. a. Principio de desarrollo incremental. b. Cada tarea es una serie de pasos para agilizar el proceso de producción. c. Cada paso se puede representar con un post-it. d. Cada post-it es colocado en la fase que corresponde de acuerdo a su estado. e. Cada post-it contiene información básica del paso: descripción + estimación de duración. f. Pueden ser usados más elementos en el tablero para detallar mejor cada actividad. g. La idea es clarificar al máximo el trabajo a realizar, las tareas asignadas, la priorización y la meta asignada. 3. Stop starting, start finish. a. Se prioriza el trabajo que está en curso en vez de comenzar tareas nuevas. b. El trabajo en curso debe estar limitado, por lo que existe un número máximo de tareas a realizar en cada fase. c. No se puede abrir una nueva tarea sin finalizar otra. 4. Control de flujo. a. No se aplica a un solo proyecto, sino que mezcla tareas y proyectos. b. Flujo de trabajo constante. c. Tareas importantes en cola y seguimiento pasivo para no interrumpir el trabajo. En la actualidad este sistema de producción altamente eficiente y efectivo, se ha venido implementando para la gestión de proyectos de desarrollo de software, teniendo principal afinidad con las metodologías ágiles. Como se mencionó anteriormente, este permite gestionar de una manera general la forma en la que se van completando las tareas, de una manera visual, permitiendo facilidades a la hora de establecer el estado del proyecto. Adicionalmente es de fácil 25

27 utilización, actualización y apropiación por parte del equipo, por lo que se convierte en una excelente herramienta para complementar la metodología de desarrollo seleccionada. 26

28 4. SEMAT (Software Engineering Method And Theory) Es una iniciativa tomada por Ivar Jacobson, Pan-Wei Ng, Paul E. McMahon, Ian Spence y Svante Lidman que busca redefinir la Ingeniería de Software por medio de lo que los autores consideran como La esencia de la Ingeniería de Software: El núcleo de SEMAT. [20] SEMAT busca dicha redefinición basándose en una teoría sólida, principios probados y las mejores prácticas aplicables a los proyectos de software, de manera que [21]: Se incluya un núcleo (Kernel) de elementos ampliamente aceptados y que se puedan extender a usos específicos. Traten asuntos tecnológicos y humanos. Los apoyen la industria, la academia, los investigadores y los usuarios. Apoyen la extensión ante los requisitos cambiantes y la tecnología. SEMAT se enfoca fundamentalmente en dos objetivos principales, y que son independientes el uno del otro [21]: Encontrar un Kernel de elementos ampliamente aceptados. Definición de una base teórica sólida. Para definir el Kernel, lo principal fue identificar un terreno común que de alguna u otra forma definiera a la Ingeniería de Software. Una vez identificado ese terreno, se determinó un conjunto de elementos esenciales que son universales a todos los esfuerzos de desarrollo de software y un lenguaje sencillo para describir métodos y prácticas. Luego de definidos los elementos esenciales, estos fueron clasificados en 2 grandes grupos, algunos, dentro de las cosas con las que siempre trabajamos cuando se desarrollan sistemas de software (Ver Ilustración 6), y los demás dentro de las cosas que siempre hacemos en dichos proyectos (Ver Ilustración 7). Estos dos grupos (y más en específico, los elementos al interior de cada uno) son lo que se conoce en SEMAT como la esencia del Kernel. [21] Ilustración 6. "Cosas con las que siempre trabajamos". (Tomado de [22]) 27

29 Ilustración 7. "Cosas que siempre hacemos". (Tomado de [22]) Una vez especificado el Kernel de SEMAT, este presenta 3 características únicas (principios fundamentales). El Kernel es accionable, extensible y práctico. Estos principios serán profundizados más adelante en la Sección 4.2. [21] Teniendo en cuenta todo el proceso anteriormente descrito, y previamente identificados los principios del Kernel de SEMAT, se puede decir que dicho Kernel proporciona [21]: Un marco de pensamiento para que los equipos razonen sobre el progreso que están haciendo y la salud de sus esfuerzos. Un terreno común para la discusión, mejoramiento, comparación e intercambio de métodos y prácticas de ingeniería de software. Un marco para que los equipos ensamblen y mejoren continuamente su forma de trabajo, mediante la composición de prácticas definidas por separado y de diverso origen. Un fundamento para la definición de medidas que no dependan de las prácticas, para evaluar la calidad del software producido y los métodos que se usan para producirlo. Y lo más importante, una forma de ayudarle a los equipos a comprender dónde están, qué deberían hacer luego y dónde necesitan mejorar. De acuerdo a esto, el Kernel asegura que todos los aspectos esenciales de la Ingeniería de software serán considerados en los proyectos. Adicionalmente, teniendo en cuenta que se trata de mantener independiente a prácticas de metodologías en específico, y que apoya los valores del Manifiesto Ágil, el Kernel valora a los individuos e interacciones por encima de los procesos y las herramientas. [21] Así mismo, considera más importante las necesidades de los miembros de cada equipo, y los valores del uso de métodos, por encima de la descripción de las definiciones de los métodos, apoyado en las mejores prácticas modernas de la ingeniería de software y permitiendo hacer uso de la metodología que se desee. [21] 4.1. Los Alfas Son elementos fundamentales del Kernel y esenciales a la Ingeniería de Software. Estos, han sido considerados como conjuntos de estados, en vez de elementos de trabajo (como documentación o herramientas de software), ya que así representan el progreso y salud del proyecto, y a la Ingeniería de Software en general no a metodologías en específico. [21] 28

30 Han sido identificados 7 Alfas, los cuales, como se mencionó anteriormente, corresponden a las cosas con las que siempre trabajamos. Cada Alfa tiene estado una serie de Estados, quienes de igual manera se encuentran asociados una lista de chequeo que especifica los criterios necesarios para alcanzar todo el estado. [21] Alfa Oportunidad ayuda a dar forma a los requerimientos del nuevo sistema de software, proporcionando una justificación para su desarrollo [23]. Es la oportunidad que une a los Stakeholders y proporciona la motivación para producir una actualización o un nuevo sistema de software. Es entendiendo la oportunidad que se puede identificar el valor y resultado deseado que los Stakeholders esperan realizar del uso del sistema de software, ya sea solo como una parte de todo el negocio, o como una solución técnica. Los estados de este Alfa son [23]: Ilustración 8. Alfa - Oportunidad. (Tomado de [23]) El Alfa Oportunidad se refiere al conjunto de circunstancias que hace que cambiar o desarrollar un sistema de software sea apropiado. Representa el entendimiento de las necesidades que comparten los Stakeholders y Ilustración 9. Estados Alfa - Oportunidad. (Tomado de [23]) 29

31 Estado Identificado Estado Solución necesaria Ilustración 10. Alfa - Oportunidad; Estado - Identificado. (Tomado de [23]) Una oportunidad comercial, social o de negocio ha sido identificada y podría ser gestionada por una solución de software. La lista de chequeo para este estado es: Ha sido identificada alguna de las siguientes cosas: Una idea para mejorar la forma de trabajar o la cuota de mercado; la aplicación de un nuevo o innovador sistema de software. Al menos uno de los Stakeholders desea hacer una inversión en mejorar la comprensión de la oportunidad y el valor asociado que genera dirigirla. Han sido identificados los demás Stakeholders que comparten la oportunidad. Ilustración 11. Alfa - Oportunidad; Estado - Solución necesaria. (Tomado de [23]) Este estado se da cuando la necesidad de una solución de software ha sido identificada. La lista de chequeo para este estado es: Han sido identificados los Stakeholders en la oportunidad y la solución propuesta. Han sido establecidas las necesidades de los Stakeholders que generan la oportunidad. Ha sido identificado cualquier problema subyacente y la raíz de sus causas. Ha sido confirmado que es necesaria una solución basada en software. Ha sido propuesta por lo menos una solución de software. 30

32 Estado Valor establecido Estado Viable Ilustración 12. Alfa - Oportunidad; Estado - Valor establecido. (Tomado de [23]) Este estado se da cuando el valor de una solución exitosa ha sido establecido. La lista de chequeo para este estado es: El valor de abordar la oportunidad ha sido cuantificado en términos absolutos o de retornos o ahorros por periodo. Ilustración 13. Alfa - Oportunidad; Estado - Viable. (Tomado de [23]) Se acuerda que una solución puede ser producida de manera rápida y lo suficientemente económica como para abordar con éxito la oportunidad. La lista de chequeo para este estado es: Ha sido bosquejada una solución. Ha sido entendido por los Stakeholders el impacto de la solución. Ha sido entendido el uso del sistema de software y el valor que este ofrece a los Stakeholders que lo financian. La solución puede ser desarrollada y desplegada teniendo en cuenta las restricciones. El riesgo asociado a la solución es aceptable y manejable. Está claro el criterio de éxito por el cual el desarrollo del sistema será juzgado. El costo de la solución es menor que el valor anticipado de la oportunidad. Los resultados deseados y requeridos de la solución, están claros y cuantificados. Las razones para el desarrollo de una solución basada en software son entendidas por todos los miembros del equipo. Es claro que la persecución de la oportunidad es viable. 31

33 Estado Dirigido Estado Beneficio acumulado Ilustración 14. Alfa - Oportunidad; Estado - Dirigido. (Tomado de [23]) Este estado se logra una vez se demuestra que la solución aborda la oportunidad. La lista de chequeo para este estado es: Ilustración 15. Alfa - Oportunidad; Estado - Beneficio acumulado. (Tomado de [23]) Este estado se da una vez el uso operacional o venta de la solución, crea valor y beneficios tangibles. La lista de chequeo para este estado es: Un sistema usable que demuestre que aborda la oportunidad, está disponible. La solución ha comenzado a acumular beneficios para los Stakeholders. Los Stakeholders acordaron que vale la pena desplegar la solución disponible. El perfil de rentabilidad de la inversión es al menos tan buena como lo esperado. Los Stakeholders están satisfechos con que la solución producida aborde a la oportunidad. 32

34 Alfa Stakeholders Ilustración 16. Alfa - Stakeholders. (Tomado de [23]) Los Stakeholders proporcionan la Oportunidad, y son la fuente de los requerimientos. Ellos están involucrados a lo largo del proceso de Ingeniería de Software con el fin de apoyar al equipo y asegurar la aceptación del sistema de software. [23] Ilustración 17. Estados Alfa - Stakeholders. (Tomado de [23]) Los Stakeholders son fundamentales para el éxito del sistema y del trabajo realizado para producirlo. Sus comentarios y aportes en general, ayudan a dar forma a todo el sistema y al software resultante. Los estados de este Alfa son [23]: 33

35 Estado Reconocido Estado Representado Ilustración 18. Alfa - Stakeholders; Estado - Reconocido. (Tomado de [23]) Este estado se produce una vez los Stakeholders han sido identificados. La lista de chequeo para este estado es: Se han identificado todos los grupos de Stakeholders que son o se verán afectados por el desarrollo y futura operación del sistema. Existen acuerdos entre los grupos de Stakeholders a ser representados. Estos deberían por lo menos financiar, usar, apoyar, y mantener el sistema. Ilustración 19. Alfa - Stakeholders; Estado - Representado. (Tomado de [23]) Los representantes de los Stakeholders han sido nombrados y se han acordado mecanismos para involucrar a los Stakeholders. La lista de chequeo para este estado es: Los representantes de los Stakeholders han acordado asumir sus responsabilidades. Los representantes de los Stakeholders están autorizados para llevar a cabo sus responsabilidades. Se han definido las responsabilidades de los representantes de los Stakeholders. Se ha acordado colaboración entre los representantes de los Stakeholders. Los representantes de los Stakeholders apoyan y respetan la forma de trabajar del equipo. 34

36 Estado Involucrado Estado De acuerdo Ilustración 20. Alfa - Stakeholders; Estado - Involucrado. (Tomado de [23]) Los representantes de los Stakeholders están activamente involucrados en el trabajo y cumplimiento de sus responsabilidades. La lista de chequeo para este estado es: Los representantes de los Stakeholders ayudan al equipo de acuerdo a sus responsabilidades. Ilustración 21. Alfa - Stakeholders; Estado - De acuerdo. (Tomado de [23]) Este estado se presenta cuando los representantes de los Stakeholders se encuentran de acuerdo. La lista de chequeo para este estado es: Los representantes de los Stakeholders están de acuerdo sobre las expectativas mínimas para el siguiente desarrollo del nuevo sistema de software. Los representantes de los Stakeholders proporcionan retroalimentación y toman parte de las decisiones de manera oportuna. Los representantes de los Stakeholders comunican de manera oportuna los cambios que serán relevantes para sus grupos de Stakeholders. Los representantes de los Stakeholders están contentos con su participación en el trabajo. Los representantes de los Stakeholders están de acuerdo con que sus aportes son valorados por el equipo y son tratados con respeto. 35

37 Los miembros del equipo están de acuerdo con que sus aportes son valorados por los representantes de los Stakeholders y son tratados con respeto. Los representantes de los Stakeholders proporcionan retroalimentación al sistema desde la perspectiva de su grupo de Stakeholders. Los representantes de los Stakeholders están de acuerdo con la forma en que sus diferentes prioridades y perspectivas están siendo balanceadas para proporcionar una clara dirección del equipo. Los representantes de los Stakeholders están de acuerdo con que el sistema está listo para ser desplegado Estado Satisfecho en uso Estado Satisfecho por el despliegue Ilustración 23. Alfa - Stakeholders; Estado - Satisfecho en uso. (Tomado de [23]) Este estado se da una vez el sistema ha reunido o excede las expectativas mínimas de los Stakeholders. La lista de chequeo para este estado es: Ilustración 22. Alfa - Stakeholders; Estado - Satisfecho por el despliegue. (Tomado de [23]) Las expectativas mínimas de los Stakeholders han sido logradas. La lista de chequeo para este estado es: Los Stakeholders están usando el nuevo sistema, y proporcionan retroalimentación de su experiencia. Los Stakeholders confirman que el nuevo sistema cumple con sus expectativas. 36

38 Alfa Requerimientos Los requerimientos son capturados como un conjunto de ítems. Estos pueden ser comunicados y almacenados de varias formas y con distintos niveles de detalle. Así como es importante que los requerimientos totales sean entendidos, es necesario que los ítems acá usados de manera individual también lo sean. Entre otras cosas esto ayudaría a determinar cuándo un sistema ya está terminado, e inclusive a determinar si un requerimiento está dentro del alcance. Los estados de este Alfa son [23]: Ilustración 24. Alfa Requerimientos Este Alfa se refiere a lo que debería hacer el software para dirigir la oportunidad y satisfacer las necesidades de los Stakeholders. [23] Es importante descubrir qué se necesita del sistema de software, compartir esto con los Stakeholders y los miembros del equipo, y usarlo para manejar el desarrollo y pruebas del nuevo sistema. [23] Ilustración 25. Estados Alfa Requerimientos. (Tomado de [23]) 37

39 Estado Concebido Estado Delimitado Ilustración 26. Alfa - Requerimientos; Estado - Concebido. (Tomado de [23]) Este estado se da una vez las necesidades del nuevo sistema de software han sido acordadas. La lista de chequeo para este estado es: Ilustración 27. Alfa - Requerimientos; Estado - Delimitado. (Tomado de [23]) El tema y propósito del nuevo sistema está claro. La lista de cheque para este estado es: El conjunto inicial de Stakeholders está de acuerdo que un nuevo sistema de software será producido. Se han identificado los Stakeholders involucrados en el desarrollo del nuevo sistema. Se han identificado los Stakeholders que usarán el sistema. Se han identificado los Stakeholders que financiarán el trabajo inicial en el sistema. Los Stakeholders están de acuerdo con el propósito del nuevo sistema. Está claro cuál será el éxito para el nuevo sistema. Hay una clara oportunidad de dirigir al nuevo sistema. Los Stakeholders tienen un entendimiento compartido del alcance de la solución propuesta. Se ha acordado la forma en que los requerimientos serán descritos. 38

40 Los mecanismos para la gestión de requerimientos están en su lugar. Está claro el esquema de priorización. Se han identificado y considerado las restricciones. Las suposiciones se han escrito claramente. El origen de los requerimientos es claro. La razón de ser de los requerimientos es clara. Los requerimientos conflictivos son identificados y atendidos. Los requerimientos comunican las características esenciales del sistema a ser liberado Estado Coherente Los escenarios de uso más importantes para el sistema pueden ser explicados. La prioridad de los requerimientos es clara. Es comprendido el impacto de implementar los requerimientos. El equipo comprende lo que será liberado, y está de acuerdo con liberarlo. Ilustración 28. Alfa - Requerimientos; Estado - Coherente. (Tomado de [23]) Los requerimientos proporcionan una descripción consistente de las características esenciales del nuevo sistema. La lista de chequeo para este estado es: Los requerimientos son capturados y compartidos con el equipo y los Stakeholders. 39

41 Estado Aceptable Los requerimientos son estables Estado Direccionado Ilustración 29. Alfa - Requerimientos; Estado - Aceptable. (Tomado de [23]) Los requerimientos del sistema describen un sistema que es aceptable por los Stakeholders. La lista de chequeo para este estado es: Los Stakeholders aceptan que los requerimientos describen una solución aceptable. La tasa de cambio de los requerimientos acordados es relativamente baja y se encuentra bajo control. El valor proporcionado por la implementación de los requerimientos es claro. Las partes de la oportunidad que son satisfechas por los requerimientos están claras. Ilustración 30. Alfa - Requerimientos; Estado - Direccionado. (Tomado de [23]) Suficientes requerimientos han tratado de satisfacer las necesidades del nuevo sistema, con el fin de que este sea aceptado por los Stakeholders. La lista de chequeo para este estado es: Suficientes requerimientos han abordado para dar como resultado un sistema aceptable a los Stakeholders. Los Stakeholders aceptan los requerimientos que reflejan exactamente lo que hace y no hace el sistema. El conjunto de requerimientos que han sido implementados proporcionan un valor claro a los Stakeholders. 40

42 El sistema de implementación de los requerimientos es aceptado por los Stakeholders como digno de hacerlo operativo Estado Cumplido Ilustración 31. Alfa - Requerimientos; Estado - Cumplido. (Tomado de [23]) Los requerimientos que han sido abordados satisfacen completamente las necesidades del nuevo sistema. La lista de chequeo para este estado es: Los Stakeholders aceptan los requerimientos más precisos y que cumplan exactamente con las necesidades del nuevo sistema. No hay elementos pendientes que no permitan al sistema ser aceptado. El sistema es aceptado por los Stakeholders ya que satisface completamente los requerimientos 41

43 Alfa - Sistema de Software Ilustración 32. Alfa - Sistema de software. (Tomado de [23]) Un sistema de software se diferencia de otros sistemas ya que a pesar de estar compuesto por una combinación de software, hardware y datos con el fin de cumplir a cabalidad con los requerimientos, este proporciona valor principalmente por medio de la ejecución de software. Dicho sistema puede ser parte de otro software, hardware, negocio o solución social más grande que la que este pretende abarcar. Los estados de este Alfa son [23]: Ilustración 33. Estados Alfa - Sistema de software. (Tomado de [23]) 42

44 Estado Arquitectura seleccionada Se han comprado, construido y reusado decisiones Estado Demostrable Ilustración 34. Alfa - Sistema de software; Estado - Arquitectura seleccionada. (Tomado de [23]) Una arquitectura ha sido seleccionada para abordar el riesgo técnico clave y cualquier restricción técnica aplicable. La lista de chequeo para este estado es: Los criterios a ser usados a la hora de seleccionar la arquitectura, han sido acordados. Las plataformas de hardware han sido identificadas. Los lenguajes de programación y tecnologías a ser usadas han sido seleccionados. Los límites del sistema son conocidos. Se han efectuado las decisiones significantes sobre la organización del sistema. Ilustración 35. Alfa - Sistema de software; Estado - Demostrable. (Tomado de [23]) Una versión ejecutable del sistema está disponible para demostrar si la arquitectura del sistema es apta para el propósito y apoya las pruebas. La lista de chequeo para este estado es: Se han demostrado las características claves de la arquitectura. El sistema puede ser ejecutado y su rendimiento medido. Se han demostrado configuraciones críticas de hardware. Se han demostrado interfaces críticas. Se ha demostrado integración con otros sistemas existentes. 43

45 Los representantes de los Stakeholders están de acuerdo con que la arquitectura demostrada es apropiada. El valor agregado propuesto por el sistema es claro Estado Usable Estado Listo Ilustración 36. Alfa - Sistema de software; Estado - Usable. (Tomado de [23]) El sistema es usable y muestra todas las características de calidad de un sistema operacional. La lista de chequeo para este estado es: El sistema puede ser operado por los Stakeholders que lo usarán. Ha sido probada la funcionalidad proporcionada por el sistema. El rendimiento del sistema es aceptable para los Stakeholders. Los niveles de defectos son aceptables para los Stakeholders. Ilustración 37. Alfa - Sistema de software; Estado - Listo. (Tomado de [23]) El sistema total ha sido aceptado para desplegarse en un entorno real. La lista de chequeo para este estado es: Está disponible la instalación y otra documentación de usuario. Los representantes de los Stakeholders aceptan el sistema como apto para su propósito. Los representantes de los Stakeholders quieren hacer al sistema operacional. El sistema está completamente documentado. El apoyo operativo está en su lugar. Se conoce el contenido de la liberación. 44

46 Estado Operacional Estado Retirado Ilustración 38. Alfa - Sistema de software; Estado - Operacional. (Tomado de [23]) El sistema es usado en un ambiente operacional. La lista de chequeo para este estado es: Ilustración 39. Alfa - Sistema de software; Estado - Retirado. (Tomado de [23]) El sistema no va a tener soporte por más tiempo. La lista de chequeo para este estado es: El sistema realizado permite a los Stakeholders usarlo. El sistema ha sido reemplazado o descontinuado. Al menos un ejemplar del sistema es completamente operacional. El sistema ya no va a ser soportado. El sistema es completamente soportado de acuerdo a los niveles de servicio acordados. No hay Stakeholders oficiales que aún usen el sistema. No se producirán más actualizaciones del sistema. 45

47 Alfa Equipo competencias y habilidades. Para tener un alto rendimiento, los equipos no solo deben trabajar bien en equipo, sino potenciar este trabajo cooperativo junto a metas bien definidas y entendidas. [23] A pesar de que un equipo está compuesto por varias personas, cada una de las cuales con habilidades distintas, la guía que proporcionan los Alfas sólo debe ser usada por una persona (líder), con el fin de evitar ambigüedades. Los estados de este Alfa son [23]: Ilustración 40. Alfa - Equipo. (Tomado de [23]) El equipo corresponde a un grupo de personas que se encuentran activamente comprometidas al interior del proyecto. Esto quiere decir, durante el desarrollo, mantenimiento, entrega o soporte del sistema de software. [23] El proyecto puede estar constituido por uno o más equipos encargados de planear y ejecutar el trabajo necesario para crear, actualizar y/o cambiar el sistema de software. [23] En la Ingeniería de Software, los equipos deben ser como en los de deportes, donde se involucra la aplicación colaborativa de diferentes Ilustración 41. Estados Alfa - Equipo. (Tomado de [23]) 46

48 Estado - Cultivado Se han identificado las competencias requeridas. Se ha determinado el tamaño del equipo. Se han definido las reglas de juego. Se ha seleccionado un modelo de liderazgo. Ilustración 42. Alfa - Equipo; Estado - Seeded. (Tomado de [23]) La misión del equipo es clara, así como el saber hacer necesario para cultivar al equipo. La lista de chequeo para este estado es: La misión del equipo ha sido definida en términos de oportunidades y resultados. Se conocen las restricciones de operación del equipo. Se han implementado mecanismos para el crecimiento del equipo. Se ha definido la composición del equipo. Se han definido las restricciones del dónde y cómo trabajar. Se han explicado las responsabilidades del equipo. El nivel de compromiso del equipo es claro. 47

49 Estado Formado Se han identificado colaboradores externos (organizaciones, equipos o personas). Se han definido mecanismos de comunicación entre el equipo. Cada miembro del equipo se compromete a trabajar como se definió Estado Colaborando Ilustración 43. Alfa - Equipo; Estado - Formado. (Tomado de [23]) El equipo ya tiene suficientes personas como para comenzar la misión. La lista de chequeo para este estado es: Se han entendido las responsabilidades individuales. Se han reclutado suficientes personas como para permitir el progreso del trabajo. Todos los miembros del equipo comprenden cómo realizar su trabajo. Todos los miembros se han reunido, y comienzan a conocerse. Los miembros del equipo comprenden sus responsabilidades y cómo estas se alinean con sus responsabilidades. Los miembros del equipo aceptan su trabajo. Ilustración 44. Alfa - Equipo; Estado - Colaborando. (Tomado de [23]) Los miembros del equipo se encuentran trabajando juntos como una unidad. La lista de chequeo para este estado es: El equipo trabaja como unidad cohesiva. La comunicación entre el equipo es abierta y honesta. El equipo está empeñado en cumplir con el objetivo. 48

50 Los miembros del equipo se conocen entre sí Estado Suspendido Estado Ejecutando Ilustración 46. Alfa - Equipo; Estado - Suspendido. (Tomado de [23]) Ilustración 45. Alfa - Equipo; Estado - Ejecutando. (Tomado de [23]) El equipo se encuentra trabajando de manera efectiva y eficiente. La lista de chequeo para este estado es: El equipo cumple consistentemente sus compromisos. El equipo se adapta continuamente al contexto cambiante. El equipo identifica y aborda los problemas sin ayuda externa. El equipo ya no es responsable de llevar a cabo su misión. La lista de chequeo para este estado es: Las responsabilidades del equipo han sido manejadas o cumplidas. Los miembros del equipo están disponibles para ser asignados a otros equipos. No se están haciendo ningún esfuerzo por el equipo para completar la misión. Se está logrando un progreso efectivo, evitando al mínimo volver a realizar trabajo ya hecho. El trabajo desaprovechado y el potencial trabajo desaprovechado es continuamente eliminado. 49

51 Alfa Trabajo La habilidad de los miembros para coordinar, organizar, estimar, completar y compartir su trabajo, tiene un profundo efecto en el cumplimiento de los compromisos y entrega de valor a los Stakeholders. Los miembros del equipo deben entender cómo llevar a cabo su trabajo, y cómo reconocer cuándo el trabajo está bien hecho. Los estados de este Alfa son [23]: Ilustración 47. Alfa - Trabajo. (Tomado de [23]) Cuando se habla de trabajo, no sólo se deben considerar las actividades que impliquen esfuerzo físico. Dentro de esta definición también se debe incluir el esfuerzo mental, ya que el objetivo del trabajo siempre va a ser generar un resultado. Más aun, se podría definir el trabajo en este contexto como, cualquier cosa que se tenga que realizar por parte del equipo, para cumplir con los objetivos de producir un sistema de software, que cumpla con los requerimientos y que esté enfocada hacia la oportunidad presentada por los Stakeholders. [23] Ilustración 48. Estado Alfa - Trabajo. (Tomado de [23]) 50

52 Estado Iniciado Estado Preparado Ilustración 49. Alfa - Trabajo; Estado - Iniciado. (Tomado de [23]) Este estado se da una vez el trabajo ha sido solicitado. La lista de chequeo para este estado es: Ilustración 50. Alfa - Trabajo; Estado - Preparado. (Tomado de [23]) Todas las precondiciones para iniciar el trabajo han sido cumplidas. La lista de chequeo para este estado es: El resultado requerido del trabajo iniciado está claro. Hay compromiso. Se ha identificado claramente cualquier restricción de rendimiento para el trabajo. Se conoce a los Stakeholders que financiarán el trabajo. Se ha identificado claramente al iniciador del trabajo. Se conoce a los Stakeholders que aceptarán los resultados. Son claros los recursos del financiamiento. Se han estimado los costos y esfuerzo del trabajo. Se ha comprendido la disponibilidad de recursos. Las políticas y procedimientos están claras. Se ha comprendido la exposición al riesgo. Se han definido y acordado con el cliente los criterios de aceptación. Es clara la prioridad del trabajo. El trabajo se ha desglosado lo suficiente como para comenzar a trabajar. 51

53 Las tareas han sido identificadas y priorizadas por el equipo y los Stakeholders. Se lleva a cabo un plan creíble. Se ha financiado para comenzar a trabajar. El equipo o algunos de los miembros están listos para comenzar a trabajar. Se han definido los puntos de integración y liberación Estado Comenzado Ilustración 51. Alfa - Trabajo; Estado - Comenzado. (Tomado de [23]) Este estado se da una vez se proceda con el trabajo. La lista de chequeo para este estado es: El trabajo de desarrollo ha sido comenzado. El progreso del trabajo es monitoreado. El trabajo está siendo desglosado en ítems de trabajo accionables con claras definiciones de hacerlo. Los miembros del equipo están aceptando y progresando en las tareas. 52

54 Estado Bajo control Las repeticiones de trabajo están bajo control. Las tareas son consistentemente completadas a tiempo y dentro de los estimados Estado Culminado Ilustración 52. Alfa - Trabajo; Estado - Bajo control. (Tomado de [23]) El trabajo va bien, el riesgo está bajo control y los niveles de productividad son suficientes para lograr un resultado satisfactorio. La lista de chequeo para este estado es: Las tareas están siendo completadas. El trabajo no planificado está bajo control. Los riesgos están bajo control así como el impacto de que ellos ocurran, y la probabilidad de que esto suceda ha sido reducida a niveles aceptables. Las estimaciones son revisadas para reflejar el rendimiento del equipo. Las métricas están disponibles para mostrar el progreso y velocidad. Ilustración 53. Alfa - Trabajo; Estado - Culminado. (Tomado de [23]) El trabajo para producir resultados ha sido finalizado. La lista de chequeo para este estado es: Todas las tareas pendientes son de mantenimiento administrativo, o relacionadas a la preparación de la siguiente pieza de trabajo. Los resultados del trabajo han sido logrados. Los Stakeholders aceptaron el sistema de software resultante. 53

55 Estado Cerrado Ilustración 54. Alfa Trabajo; Estado Cerrado. (Tomado de [23]) Todas las tareas de mantenimiento restantes han sido completadas y el trabajo es oficialmente cerrado. La lista de chequeo para este estado es: Las lecciones aprendidas han sido detalladas, registradas y discutidas. Se han puesto a disposición las métricas. Todo ha sido archivado. El presupuesto ha sido conciliado y cerrado. El equipo ha sido liberado. No hay tareas pendientes ni incompletas. 54

56 Alfa - Forma de trabajar implica cualquier proceso de Ingeniería de Software. Los estados de este Alfa son [23]: Ilustración 55. Alfa - Forma de trabajar. (Tomado de [23]) La forma de trabajar se puede ver como el conjunto de prácticas y herramientas usadas por un equipo para guiar y soportar su trabajo. [23] El equipo evoluciona su forma de trabajar a medida que entiende mejor su misión y su ambiente de trabajo. Esta forma de trabajo es adaptativa y va cambiando de acuerdo al contexto. [23] Ilustración 56. Estados Alfa - Forma de trabajar. (Tomado de [23]) El equipo debe entender que es un equipo, y que esto implica trabajo colaborativo, para lo que es necesario que entre los mismos miembros se hagan acuerdos de cooperación que los guíen durante el esfuerzo que 55

57 Estado Principios establecidos Estado Bases establecidas Ilustración 57. Alfa Forma de trabajar; Estado Principios. (Tomado de [23]) Los principios y restricciones que dan forma a la manera de trabajar, son establecidos. La lista de chequeo para este estado es: Los principios y restricciones son pactados por el equipo. Los principios y restricciones son acordados por los Stakeholders. Se acordaron las necesidades de herramientas de trabajo y sus Stakeholders. Una recomendación para el enfoque a seguir está disponible. Es entendido el contexto dentro del cual el equipo operará. Son conocidas las restricciones que se aplican a la selección, adquisición y uso de prácticas y herramientas. Ilustración 58. Alfa Forma de trabajar; Estado Bases establecidas. (Tomado de [23]) Las prácticas clave y herramientas que originan las bases de la forma de trabajar, son seleccionadas y están listas para su uso. La lista de chequeo para este estado es: Son seleccionadas las prácticas clave y herramientas que formarán las bases de la forma de trabajar. Han sido acordadas por el equipo suficientes prácticas para comenzar a trabajar. Han sido identificadas todas las prácticas y herramientas no negociables. Han sido analizada y entendida la brecha que existe entre las prácticas y herramientas que son necesarias y las prácticas y herramientas que están disponibles. 56

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

PROPUESTA PARA TRABAJO DE GRADO

PROPUESTA PARA TRABAJO DE GRADO Ingeniería de Sistemas TÍTULO PROPUESTA PARA TRABAJO DE GRADO Guía para la integración de métodos formales de ingeniería de requerimientos en procesos de desarrollo ágil MODALIDAD Ayuda Didáctica OBJETIVO

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

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

Guia Nexus. La Guía Definitiva de Nexus: El exoesqueleto del Desarrollo de Scrum Escalable. Desarrollado y mantenido por Ken Schwaber y Scrum.

Guia Nexus. La Guía Definitiva de Nexus: El exoesqueleto del Desarrollo de Scrum Escalable. Desarrollado y mantenido por Ken Schwaber y Scrum. Guia Nexus La Guía Definitiva de Nexus: El exoesqueleto del Desarrollo de Scrum Escalable Desarrollado y mantenido por Ken Schwaber y Scrum.org Agosto 2015 Contenido Vision General de Nexus... 2 Proposito

Más detalles

DES. Fundamento Institucional. Objetivos. Alcance

DES. Fundamento Institucional. Objetivos. Alcance DES INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de DESARROLLO en el ciclo de vida del software en el cual se debe apoyar para la ejecución de sus actividades;

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

SCRUM. Gestión ágil de proyectos

SCRUM. Gestión ágil de proyectos SCRUM Gestión ágil de proyectos 1 Qué es Scrum? SCRUM es una metodología ágil utilizada en el desarrollo de proyectos de software y que permite obtener el mejor resultado posible en la gestión de un proyecto

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

CIS1410IS07 GUÍA PARA LA INTEGRACIÓN DE MÉTODOS FORMALES DE INGENIERÍA DE REQUERIMIENTOS EN PROCESOS DE DESARROLLO ÁGIL JUAN DARÍO MURCIA TORRES

CIS1410IS07 GUÍA PARA LA INTEGRACIÓN DE MÉTODOS FORMALES DE INGENIERÍA DE REQUERIMIENTOS EN PROCESOS DE DESARROLLO ÁGIL JUAN DARÍO MURCIA TORRES CIS1410IS07 GUÍA PARA LA INTEGRACIÓN DE MÉTODOS FORMALES DE INGENIERÍA DE REQUERIMIENTOS EN PROCESOS DE DESARROLLO ÁGIL JUAN DARÍO MURCIA TORRES PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA

Más detalles

La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego. Julio de 2013. Desarrollado y soportado por Ken Schwaber y Jeff Sutherland

La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego. Julio de 2013. Desarrollado y soportado por Ken Schwaber y Jeff Sutherland La Guía de Scrum La Guía Definitiva de Scrum: Las Reglas del Juego Julio de 2013 Desarrollado y soportado por Ken Schwaber y Jeff Sutherland Contenido Propósito de la Guía de Scrum... 4 Visión general

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

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

La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego. Octubre de 2011. Desarrollado y soportado por Ken Schwaber y Jeff Sutherland

La Guía de Scrum. La Guía Definitiva de Scrum: Las Reglas del Juego. Octubre de 2011. Desarrollado y soportado por Ken Schwaber y Jeff Sutherland La Guía de Scrum La Guía Definitiva de Scrum: Las Reglas del Juego Octubre de 2011 Desarrollado y soportado por Ken Schwaber y Jeff Sutherland Contenido Propósito de la Guía de Scrum... 3 Visión general

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

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

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

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

Más detalles

La Guía Nexus. La Guía Definitiva a Nexus: El exoesqueleto de desarrollo a escala con Scrum. Desarrollado y mantenido por Ken Schwaber y Scrum.

La Guía Nexus. La Guía Definitiva a Nexus: El exoesqueleto de desarrollo a escala con Scrum. Desarrollado y mantenido por Ken Schwaber y Scrum. La Guía Nexus La Guía Definitiva a Nexus: El exoesqueleto de desarrollo a escala con Scrum Desarrollado y mantenido por Ken Schwaber y Scrum.org Agosto 2015 Tabla de Contenido Información General de Nexus...

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

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

Cómo las metodologías ágiles ayudan a los proyectos de Inteligencia de Negocios

Cómo las metodologías ágiles ayudan a los proyectos de Inteligencia de Negocios Cómo las metodologías ágiles ayudan a los proyectos de Inteligencia de Negocios Guillermo Watson Datalytics Stibenzon Cañas Sánchez Ceiba Software House Business Intelligence No es una tecnología ni un

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

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

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

Más detalles

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]:

RESUMEN DE COBIT 4.1. Los recursos de TI identificados en COBIT se pueden definir como sigue [2]: RESUMEN DE COBIT 4.1 COBIT es un marco de trabajo y un conjunto de herramientas de Gobierno de Tecnología de Información (TI) que permite a la Gerencia cerrar la brecha entre los requerimientos de control,

Más detalles

Curso. Introducción a la Administracion de Proyectos

Curso. Introducción a la Administracion de Proyectos Curso Introducción a la Administracion de Proyectos Tema 5 Procesos del área de Integración INICIAR PLANEAR EJECUTAR CONTROL CERRAR Desarrollar el Acta de Proyecto Desarrollar el Plan de Proyecto Dirigir

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

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

LOS INDICADORES DE GESTIÓN

LOS INDICADORES DE GESTIÓN LOS INDICADORES DE GESTIÓN Autor: Carlos Mario Pérez Jaramillo Todas las actividades pueden medirse con parámetros que enfocados a la toma de decisiones son señales para monitorear la gestión, así se asegura

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producció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

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

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

Ingeniería de Software II Segundo Cuatrimestre de 2008

Ingeniería de Software II Segundo Cuatrimestre de 2008 Ingeniería de Software II Segundo Cuatrimestre de 2008 Clase 14: Introducción a los métodos ágiles y Scrum Buenos Aires, 9 de Octubre de 2008 Scrum: Qué es? Qué es un scrum? Un scrum es un agrupamiento

Más detalles

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

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

Más detalles

Aplicación de metodologías Ágiles en TI. Elsa Mangione, PMP, PMI-ACP, CSM II Reunión de Miembros Abierta. Mendoza, 2013.

Aplicación de metodologías Ágiles en TI. Elsa Mangione, PMP, PMI-ACP, CSM II Reunión de Miembros Abierta. Mendoza, 2013. Aplicación de metodologías Ágiles en TI Elsa Mangione, PMP, PMI-ACP, CSM II Reunión de Miembros Abierta. Mendoza, 2013. 1 To Do En Proceso Done! Agile Scrum Intro Lean Kanban Aplicabilidad Cierre 2 To

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

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

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S4 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

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

1. PROCESOS DEL PROJECT MANAGEMENT

1. PROCESOS DEL PROJECT MANAGEMENT INDICE 1. PROCESOS DEL PROJECT MANAGEMENT 1.1 Procesos del Proyecto 1.2 Grupos de Proceso 1.3 Interacciones del Proceso 1.4 Adaptación de las interacciones del proceso 2. AREAS DEL CONOCIMIENTO DEL PROJECT

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

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN Principios y criterios para la evaluación del ciclo de vida de desarrollo de sistemas Se pueden enunciar algunos principios para desarrollar

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

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

Reporte inicial. Metodología

Reporte inicial. Metodología Reporte inicial Este reporte inicial expondrá las decisiones que tomamos al momento de selección de metodología, plantillas y métodos de recabado de evidencia y por qué tomamos dichas decisiones. Metodología

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

Trabajo Práctico Integrador

Trabajo Práctico Integrador Trabajo Práctico Integrador Objetivo: Relacionar los conceptos vistos durante la cursada bajo una actividad práctica en la que los alumnos puedan aplicar los conceptos a la luz de un contexto organizacional.

Más detalles

EJECUCIÓN CURSO EN GERENCIA DE PROYECTOS. ANDRÉS VÁSQUEZ Ingeniero de Sistemas y Computación Especialista en Gerencia de Proyectos

EJECUCIÓN CURSO EN GERENCIA DE PROYECTOS. ANDRÉS VÁSQUEZ Ingeniero de Sistemas y Computación Especialista en Gerencia de Proyectos CURSO EN GERENCIA DE PROYECTOS EJECUCIÓN ANDRÉS VÁSQUEZ Ingeniero de Sistemas y Computación Especialista en Gerencia de Proyectos EDT Las divisiones del trabajo en diferentes niveles, dependerán de varios

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

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

Más detalles

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0 Centro Ideoinformática Universidad de las Ciencias Informáticas Carretera a San Antonio Km 2 ½. Torrens. Boyeros. Ciudad de La Habana. Cuba Teléfono: + 53 (7)

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

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 Estándares para planes de calidad de software Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 DIFERENCIA ENTRE PRODUCIR UNA FUNCION Y PRODUCIR UNA FUNCION

Más detalles

Software. Ingeniería en Sistemas Computacionales

Software. Ingeniería en Sistemas Computacionales 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Metodologías Ágiles de Desarrollo de Software Ingeniería en Sistemas Computacionales Clave de la asignatura: ARC-1304 (Créditos) SATCA1 2-2-4

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

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

Qué es scrum? scrumshortcuts.com

Qué es scrum? scrumshortcuts.com Qué es scrum? scrumshortcuts.com Qué es scrum? SCRUM es una metodología ágil de gestión de proyectos cuyo objetivo primordial es elevar al máximo la productividad de un equipo. La metodología scrumshortcuts.com

Más detalles

Gestión de Calidad. Calidad de Software UNIVERSIDAD MAYOR DE SAN SIMON FACULTAD DE CIENCIAS Y TECNOLOGIA CARRERA DE INGENIERIA DE SISTEMAS

Gestión de Calidad. Calidad de Software UNIVERSIDAD MAYOR DE SAN SIMON FACULTAD DE CIENCIAS Y TECNOLOGIA CARRERA DE INGENIERIA DE SISTEMAS UNIVERSIDAD MAYOR DE SAN SIMON FACULTAD DE CIENCIAS Y TECNOLOGIA CARRERA DE INGENIERIA DE SISTEMAS Gestión de Calidad Calidad de Software Nombre: Vargas Arteaga Vanessa Alejandra Docente: Valentín Laime

Más detalles

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008)

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008) Unidades temáticas de Ingeniería del Software Fases del proceso de desarrollo 4ª edición (2008) Facultad de Informática organización del desarrollo El ciclo de vida del software abarca el proceso de desarrollo,

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

B.2.2. Principios para la gestión de proyectos

B.2.2. Principios para la gestión de proyectos B.2.2. Principios para la gestión de proyectos La gestión de proyectos es la aplicación de conocimientos, conocimiento técnico, herramientas y técnicas para planificar actividades a fin de satisfacer o

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S3 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

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

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

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

1 de junio de 2014. Andrés Simón Bujaidar Director Alianzas Nacionales MEXICO FIRST Presente. Estimado Andrés:

1 de junio de 2014. Andrés Simón Bujaidar Director Alianzas Nacionales MEXICO FIRST Presente. Estimado Andrés: 1 de junio de 2014. Andrés Simón Bujaidar Director Alianzas Nacionales MEXICO FIRST Presente. Estimado Andrés: A continuación me permito poner a tu consideración la propuesta de los programas de certificación

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

Roles Scrum en Profundidad. ScrumMaster, Product Owner, Team

Roles Scrum en Profundidad. ScrumMaster, Product Owner, Team Roles Scrum en Profundidad ScrumMaster, Product Owner, Team Interdependencia entre Roles El verdadero proyecto lo llevan el Product Owner y el Team, mientras que el Scrum Master facilita la interacción.

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

Prototipado Ágil. Mateu Batle Sastre

Prototipado Ágil. Mateu Batle Sastre Prototipado Ágil Mateu Batle Sastre Uso informativo y confidencial Prototipado Ágil Prototipos Metodologías ágiles Metodología Scrum Definición de prototipo Ejemplar original o primer molde en que se fabrica

Más detalles

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

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

Más detalles

Las Normas ISO 9000 del 2000

Las Normas ISO 9000 del 2000 Las Normas ISO 9000 del 2000 La serie de Normas ISO 9000 son un conjunto de enunciados, los cuales especifican que elementos deben integrar el Sistema de Gestión de la Calidad de una Organización y como

Más detalles

E 2.4.1 Documento de entrega de Aplicación

E 2.4.1 Documento de entrega de Aplicación E 2.4.1 Documento de entrega de Aplicación Versión: 0.1 Fecha: 11/08/11 Autor: Email: Antoni Bertran Bellido abertran@opentrends.net Historial de cambios Versión Fecha Autor Cambios 0.1 11/08/11 Antoni

Más detalles

MEMORIA DE LAS ACTIVIDADES DESARROLLADAS PROYECTOS DE INNOVACIÓN EDUCATIVA CURSO 2014/2015

MEMORIA DE LAS ACTIVIDADES DESARROLLADAS PROYECTOS DE INNOVACIÓN EDUCATIVA CURSO 2014/2015 MEMORIA DE LAS ACTIVIDADES DESARROLLADAS PROYECTOS DE INNOVACIÓN EDUCATIVA CURSO 2014/2015 DATOS IDENTIFICATIVOS: 1. Título del Proyecto Herramienta para el Desarrollo de Aplicaciones Software con Metodologías

Más detalles

LISTA DE CHEQUEO NORMA NTC ISO 9001:2000 No. REQUISITOS EXISTE ESTADO OBSERVACIONES D: Documentado I: Implementado M: Mejorar SI NO D I M

LISTA DE CHEQUEO NORMA NTC ISO 9001:2000 No. REQUISITOS EXISTE ESTADO OBSERVACIONES D: Documentado I: Implementado M: Mejorar SI NO D I M No. REQUISITOS EXISTE ESTADO OBSERVACIONES 4. SISTEMA DE GESTION DE LA CALIDAD 4.1 Requisitos Generales La organización debe establecer, documentar, implementar y mantener un S.G.C y mejorar continuamente

Más detalles

Metodologías de Desarrollo de Sistemas de Información

Metodologías de Desarrollo de Sistemas de Información Metodologías de Desarrollo de Sistemas de Información Metodología para el Desarrollo de SI Las metodologías son sistemas completos de técnicas que incluyen procedimientos paso a paso, productos resultante,

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

Las Normas ISO 9000. Puede ser un producto material, un producto informático, servicio, información, etc.

Las Normas ISO 9000. Puede ser un producto material, un producto informático, servicio, información, etc. Las Normas ISO 9000 La serie de Normas ISO 9000 son un conjunto de enunciados, los cuales especifican que elementos deben integrar el Sistema de Gestión de la Calidad de una Organización y como deben funcionar

Más detalles

SIS 301 Operación y mantenimiento 15 minutos

SIS 301 Operación y mantenimiento 15 minutos SIS 301 Operación y mantenimiento 15 minutos O Generalidades 1 Planificación 2 Procedimientos 3 Responsabilidades del personal de operación 4 Responsabilidades del personal de mantenimiento 5 Mantenimiento

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

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

Boletín de Asesoría Gerencial* Business Process Management (BPM)

Boletín de Asesoría Gerencial* Business Process Management (BPM) Espiñeira, Sheldon y Asociados * No. 11-2009 *connectedthinking Contenido Haga click en los enlaces para navegar a través del documento Haga click en los enlaces para llegar directamente a cada sección

Más detalles

Ingeniería de Software II Primer Cuatrimestre de 2008

Ingeniería de Software II Primer Cuatrimestre de 2008 Ingeniería de Software II Primer Cuatrimestre de 2008 Clase 14: Introducción a Scrum Buenos Aires, 12 de Mayo de 2008 Scrum: Qué es? Qué es un scrum? Un scrum es un agrupamiento (formación fija) en Rugby.

Más detalles

UNIVERSIDAD TECNICA DE MANABI Facultad de Ciencias Informáticas Ingeniería en sistemas. SEGURIDAD INFORMATICA Tema:

UNIVERSIDAD TECNICA DE MANABI Facultad de Ciencias Informáticas Ingeniería en sistemas. SEGURIDAD INFORMATICA Tema: UNIVERSIDAD TECNICA DE MANABI Facultad de Ciencias Informáticas Ingeniería en sistemas SEGURIDAD INFORMATICA Tema: CATEGORÍAS DE BENEFICIOS DE ESTANDARES Y PROCEDIMIENTOS Integrantes Doris María Mera Mero

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

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

JUSTO A TIEMPO (JIT)

JUSTO A TIEMPO (JIT) PÁG. 1 DE 9 1. QUÉ ES? Just in time (que también se usa con sus siglas JIT), literalmente quiere decir Justo a tiempo. Es una filosofía que define la forma en que debería optimizarse un sistema de producción.

Más detalles

Describir el CMMI para el desarrollo de software, evolución, alcance y representación

Describir el CMMI para el desarrollo de software, evolución, alcance y representación Unidad 6: Introducción a CMMI Objetivo terminal de la Unidad Describir el CMMI para el desarrollo de software, evolución, alcance y representación Temas: Acerca del Modelo Capacidad Madurez Evolución de

Más detalles

MODELOS Y SISTEMAS DE CALIDAD EN LA EDUCACIÓN

MODELOS Y SISTEMAS DE CALIDAD EN LA EDUCACIÓN MODELOS Y SISTEMAS DE CALIDAD EN LA EDUCACIÓN OBJETIVO GENERAL El alumno analizará, la importancia de brindar productos y servicios con calidad; así como estudiar los fundamentos, autores y corrientes

Más detalles

Gerencia de Proyectos, un enfoque. Marco de referencia

Gerencia de Proyectos, un enfoque. Marco de referencia Gerencia de Proyectos, un enfoque Directivo Marco de referencia Confidencialidad Este documento está dirigido a las personas que participan en este seminarioynopuedeserreproducidoocopiadodemaneraalguna,entodoo

Más detalles

Especificación de Requisitos según el estándar de IEEE 830

Especificación de Requisitos según el estándar de IEEE 830 Especificación de Requisitos según el estándar de IEEE 830 IEEE Std. 830-1998 22 de Octubre de 2008 Resumen Este documento presenta, en castellano, el formato de Especificación de Requisitos Software (ERS)

Más detalles

DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE

DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE DESARROLLO DE SOFTWARE DEFINICIÓN GENERAL DEL PROCESO GABY LORENA GUERRERO LEYDI ROCIO ERAZO PABLO FELIPE MIRANDA WALTER ALEXIS ANTE UNIVERSIDAD DEL CAUCA FACULTAD DE INGENIERÍA ELECTRÓNICA Y TELECOMUNICACIONES

Más detalles

Roles y Responsabilidades en la gestión de proyectos Scrum

Roles y Responsabilidades en la gestión de proyectos Scrum en la gestión de proyectos Scrum Jesús E Méndez A #WebinarGratis 1 Quien es Jesus Mendez Coach Agile (2) Twitter: @chuzzete Web site: www.jesusmendez.ca Correo: info@jesusmendez.ca Scrum Master (5) + Volunteering

Más detalles

PRU. Fundamento Institucional. Objetivos. Alcance

PRU. Fundamento Institucional. Objetivos. Alcance PRU INSTRUCCIONES: a continuación se describe el flujo de trabajo correspondiente al área de procesos de PRUEBAS para el desarrollo de software, en el cual se debe apoyar para la ejecución de sus actividades;

Más detalles

MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS

MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS MÉTODO PARA EL ANÁLISIS, DISEÑO Y DESARROLLO DE MICROSISTEMAS Existen diversos métodos para desarrollar un sistema de información o un microsistema, pero en esencia todos parten de los mismos principios

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