Metodologías de desarrollo de software

Transcripción

1 Universidad de Costa Rica Sede Occidente Bachillerato en Informática Empresarial Curso: Ingeniería del software Profesor: Oscar Alfaro Solis Metodologías de desarrollo de software Realizado por: Diego Leonardo Arias Mora Jean Paul Barquero Carvajal María José Fonseca Álvarez

2 Qué es una metodología de desarrollo de software? 3 Enfoques de un proyecto 3 Enfoque predictivo 3 Ciclo de vida iterativo e incremental 4 Enfoque adaptativo 4 Kanban 5 Funcionamiento 5 Diferencias con Scrum Error! Marcador no definido. Ventajas de utilizar kanban: 8 Desventajas de Kanban 8 Rapid Application Development 10 Proceso cíclico de RAD 10 Beneficios de los prototipo 11 Ventajas de RAD 12 Desventajas de RAD 13 Desarrollo de software basado en componentes 14 Estadísticas de reutilización de código 14 Características de un componente 15 Etapas 16 Ventajas y desventajas 19 Conlusiones 21 Anexos 21 Caso de estudio de Kanban Error! Marcador no definido. Caso de estudio de Rapid Application Development 21 Caso de estudio de Desarrollo Basado en Componentes 21 Bibliografía 22

3 Qué es una metodología de desarrollo de software? Es difícil encontrar una definición estándar para una metodología de desarrollo de software, sin embargo es posible identificar algunas de las utilizadas por algunas empresas o compañías que se dedican a esta tarea. Un ejemplo de esto es Centers for medicare & medicaid services o CMS (2017), quienes definen una metodología de desarrollo de software como un marco de trabajo que es usado para estructurar, planificar y controlar el proceso de desarrollo de un sistema de información. Por otra parte, en la revista electrónica International Journal of Computer Applications define una metodología de desarrollo como un proceso mediante el cual un proyecto de software es completado o desarrollado a través de procesos o etapas bien definidas. (Chandra, 2015). Enfoques de un proyecto Enfoque predictivo El enfoque predictivo se basa en realizar una planeación inicial realmente detallada. Desde la fase temprana de un proyecto, se determinan el alcance del mismo, el costo que representa y el tiempo en el que se debe concluir y las partes involucradas en el proyecto se comprometen a cumplir con lo que se establece en esa planeación. Es sumamente formal e implica una aceptación por cada una de las partes involucradas, debido al alto riesgo que representa una planificación completa del proyecto. (Monreal, 2014). Los proyectos con este enfoque normalmente se estructuran en una serie de etapas bien definidas que deben cumplirse una a una para continuar con la siguiente. Cada una de estas fases establece tareas distintas, por lo que el equipo del proyecto va cambiando conforme vaya avanzando. Este enfoque tiene un nivel de detalle y previsión sumamente alto, especifica cada actividad que se va a realizar durante el desarrollo del proyecto e incluso su fecha de inicio y de

4 fin. Cualquier cambio aceptado en este ciclo de vida implica una replanificación del proyecto completo y una reaceptación del mismo. Este enfoque es recomendado para proyectos donde un nivel preciso de detalle de todo el proyecto es realmente necesario desde el inicio y del cual se tiene amplio conocimiento y un nivel de definición del entregable final sumamente claro. Ciclo de vida iterativo e incremental En este enfoque el trabajo y el tiempo se divide en bloques, como si se tratará de mini proyectos que conforman uno más grande. En cada iteración se hace la recolección de requerimientos, su documentación, planear la iteración, pruebas e implementación para poder otorgarle al cliente un producto funcional al final de cada una de estas iteraciones. Este enfoque viene a tratar de mejorar los ciclos de vida en donde se planea todo desde el principio, por ejemplo cascada. La idea es adquirir retroalimentación para mejorar el producto en la siguiente iteración. Este enfoque se recomienda para proyectos en los que se necesite tener retroalimentación continua del cliente. Además se recomienda cuando hay muchos requerimientos y no se tiene claro todo lo que hay que hacer desde el principio. Enfoque adaptativo Los ciclos de vida adaptativos son también conocidos como métodos ágiles. Este enfoque pretende responder a altos niveles de cambio y a la participación continua de los involucrados. Los métodos adaptativos también son iterativos e incrementales, pero difieren de estos en la duración, debido a que en el enfoque adaptativo generalmente se ejecutan varios procesos en cada iteración, además, el ciclo de vida adaptativo tiene los costos y la duración son fijos (PMBOK, 5ta Edición). Al comienzo de una iteración el equipo trabaja en determinar cuántos elementos de alta prioridad pueden entregar en la siguiente iteración. Al final de cada iteración el producto debe de estar listo para su revisión por el cliente y este puede rechazar el producto, aceptarlo o proponer algún cambio para la siguiente iteración. Este ciclo de vida requiere que el cliente esté involucrado en el proyecto continuamente para proporcionar retroalimentación (PMBOK, 5ta Edición).

5 Ejemplos de metodologías de desarrollo Kanban Kanban es una palabra japonesa que significa carta o tarjeta, el cual representa esta metodología de trabajo. Kanban es una metodología ágil de desarrollo, ya que se adapta a los requerimientos cambiantes del usuario y los avances se entregan de manera incremental. Kanban fue creado por Toyota en un momento en el que requerían organizar su manera de producción, para ello dividieron las etapas para lograr controlar la calidad y cada una de esas etapas deben realizarse una después de otra. Este proceso se ha renovado y a pasado a constituir una metodología para poder ser implementada en el desarrollo del software, de manera que fue implementada por Microsoft por primera vez y desde ese momento se ha utilizado en diferentes veces por todo el mundo. (Kniberg Henrik, 2009) Esta metodología se rige por dos objetivos que hay que seguir, el primero es lograr hacer un producto de calidad y hacer que cada fase del proyecto termine de manera correcta. Funcionamiento Esta metodología funciona de manera que se usan señales para comunicar cuando en una fase de un proyecto hace falta trabajo, por ejemplo si en una fase específica, hay poco trabajo, la fase actual va a pedir a la fase anterior una nueva tarea, de manera que solo se toma el trabajo cuando este se acabe, generando así un método para trabajar solamente con una cantidad establecida de trabajo. Primeramente se debe definir qué etapas se van a llevar a cabo en un proyecto, de esa manera se identificarán procesos por ejemplo análisis, diseño, desarrollo, pruebas y entrega. Entonces se segmenta todo lo que hay que hacer en etapas, luego estas etapas serán las columnas en una matriz que será el tablero en el que las diferentes tareas pasarán por los distintos estados.

6 Así cada quien podrá saber cómo se va desarrollando cada tarea. A continuación se presenta una imagen de un tablero Kanban con sus secciones divididas. Las columnas deben ser divididas también en 3 secciones, la primera es en progreso que significa que la tarea está haciendo en este momento, la siguiente es la subcolumna de seguimiento que indica que la tarea está bloqueada por alguna razón, ya sea que depende de otra o que está en espera porque otra persona debe realizarla, por ejemplo cuando hay una tarea en la que una persona sea más hábil que otra y la última subcolumna se llama listo en la que las tareas ya han pasado por las condiciones de la definición de listo del equipo para saber que esa tarea ha cumplido con los estándares de calidad y es aceptable, por lo que no hay un miembro con un rol específico que las acepte, sino que los miembros de equipo, junto con las restricciones del producto se aseguran de que la tarea esté bien validada. Fuente: Las tareas pueden llevar algunos atributos para poder tener más control sobre lo que se hace: pueden ser: Fecha de creación Fecha tope Creado por

7 Prioridad Tipo de tarea Descripción Notas Definición o Requisitos para "Completo / Terminado" Historia Ahora que el tablero está lleno y con las tareas dentro, se debe definir cuánto será el trabajo que se puede hacer por parte de cada miembro del grupo, a esta medida se le llama límite WIP. Este límite tiene como propósito medir la cantidad de trabajo ideal para realizar tareas, de esta manera se puede hacer que el equipo de trabajo gane 2 beneficios, de manera que una persona se concentra más en una tarea a la vez, esta podrá ser realizada con más eficiencia y podrá dar un resultado de mayor calidad ya que se enfoca en hacer solamente una cosa a la vez y terminarla antes de comenzar una nueva. Ahora que se tienen límites de trabajo establecido, es posible saber cuánta carga tiene cada miembro del equipo y se debe intentar no pasar ese limite, ademas de que se deben establecer reglas en caso de que alguien quiera pasar esos límites de manera que se pueden hacer reuniones para hablar y discutir sobre que pasa actualmente. Normalmente una tarea se asigna a la persona que decide hacerla y tomarla de la pila de tareas para hacer. Cuando se asignan las tareas y el límite de trabajo está bien establecido, es posible saber cuando se forma un cuello de botella entre las tareas que se deben hacer. Kanban se especializa en solventar este tipo de problemas ya que puede hacer evidente un cuello de botella desde etapas tempranas y esto significa que se puede solucionar de manera mas rapida tambien. Entonces las personas de un equipo de trabajo se pueden establecer un límite de por ejemplo 2 ítems de la lista de tareas para trabajar a la vez, es importante recalcar que entre menos tareas se hagan a la vez es mejor, por lo tanto tener un límite bajo es lo ideal como lo indica Brechner en su libro Microsoft Press Agile Project Management with Kanban (Brechner, 2015). Es importante saber que existen 2 maneras de medir la duración y capacidad del equipo.

8 La primera es usar el Lead time que es el tiempo que pasa desde que alguien toma una tarea, aunque no la haya comenzado, hasta que la termina y la segunda el Cycle time que es el tiempo que pasa desde que alguien comienza la tarea hasta que la termina. De esta manera se puede también hacer un estimado de cuánto tiempo se podrá tardar en entregar un paquete de software o un conjunto de funcionalidades. (López, 2013). Es importante reunirse para discutir sobre métricas, sobre el proceso, lo que se ha logrado y como se ha sentido el proceso, para esto kanban no especifica el tempo para hacer reuniones pero sí recomienda hacerla una vez por semana, al final de un entregable o bien cuando ocurra un problema. Ventajas de utilizar kanban: Primeramente es posible reducir el trabajo en proceso con el WIP, ya que es el punto fuerte de Kanban realizar poco trabajo a la vez. No tiene muchas reglas que aplicar, por lo tanto aprenderlo es fácil Ayuda a fomentar el trabajo en equipo ya que el equipo de desarrollo debe comunicarse constantemente. Nunca se pierde el tiempo ya que todo el trabajo se rige por la demanda de las tareas y si pasara que alguien se queda sin trabajo es posible ayudar a otros. Es fácil ver cómo se desarrolla el proyecto con solo ver el tablero, el cual da una visión general pero completa. Desventajas de Kanban El trabajo puede hacerse complejo al haber pocas reglas para los inexpertos o los nuevos del equipo, por lo tanto se recomienda kanban cuando ya hay confianza entre los miembros del equipo. Kanban no ayuda a predecir los problemas, solo se pueden ver cuando ya están pasando.

9

10 Rapid Application Development Rapid application development es una metodología que hace énfasis en minimizar la planeación, por lo que no posee un enfoque predictivo. RAD se enfoca en realizar prototipos y utilizar componentes reutilizables. Al utilizar la metodología rapid application development los diseñadores y los desarrolladores pueden utilizar su conocimiento y lecciones aprendidas sobre el proyecto para dar forma al diseño o adaptar el software a la dirección correcta. La metodología rapid application development tiene enfoques ligeramente distintos, pero la mayoría de sus enfoques tienen algo en común, y eso es el desarrollo de prototipos (Powell, 2016). Es una buena decisión utilizar RAD cuando el prototipo del producto es lo suficientemente bueno para qué se implemente en el producto final y de esta forma se reutilicen los componentes. Proceso cíclico de RAD Fuente: 1. Requisitos de planificación: Durante la etapa inicial, los diseñadores, desarrolladores y usuarios llegan a un acuerdo acerca del alcance del proyecto y los requerimientos de la aplicación, para desarrollar en etapas futuras el prototipo. 2. Diseño del usuario: La opinión de el usuario es tomada en cuenta para determinar el flujo de datos y la arquitectura del sistema. Esto permite que desde

11 el inicio se puedan crear modelos y prototipos. Este paso se repite cuantas veces se necesario y dependiendo de la evolución del proyecto. 3. Construcción rápida: Una vez que el diseño del usuario y el diseño del sistema han comenzado, toma parte la fase de construcción rápida. La construcción rápida es la etapa en donde ocurre la codificación, testing y la integración del sistema. Esta etapa se repite cuantas veces sea necesario, ya sea que se requiera un nuevo componente o se solicite un cambio en el sistema. 4. Transición: La etapa de transición permite al equipo de desarrollo mover los entregables a un ambiente de producción en caso de que sea requerido. En la etapa de transición puede ocurrir un team training, el cual se podría comparar con un Spike en la metodología de Scrum (Powell, 2016). Uno de los mayores beneficios de RAD es la capacidad de recibir feedback con facilidad y frecuencia, gracias a que los usuarios están constantemente interactuando directamente con el prototipo durante la creación o desarrollo del mismo. El que el usuario interactúe con el prototipo directamente significa además que el usuario puede estar a la vanguardia del proceso de desarrollo. Beneficios de los prototipo El uso de prototipos durante todo el ciclo de desarrollo conlleva distintos beneficios, tales como: Participación del usuario: En un modelo en cascada, el equipo de diseño discute con los usuarios las características o implementaciones que podría necesitar el proyecto o sistema. A diferencia de dicho modelo, RAD permite a los usuarios utilizar el software y proporcionar retroalimentación sobre un sistema, en lugar de tratar de proporcionar evaluaciones abstractas de un documento de diseño. Viabilidad: RAD permite al equipo de desarrollo evaluar rápidamente la factibilidad o complejidad de un componente, para trabajar en los más complejos a principio del ciclo de vida. Debido a esto, el software podrá

12 ser más robusto, menos propenso a errores y se podrán implementar mejoras próximas en el diseño Reducción y depuración de errores: Con las versiones de prototipos rápidos durante un proyecto, es más probable detectar errores antes del ciclo de desarrollo que si utilizamos un enfoque tradicional (Powell, 2016). Ventajas de RAD Ventajas al utilizar RAD como metodología de desarrollo: Progreso medible: Con frecuentes iteraciones, componentes y prototipos, puede ser fácilmente medido para mantener el proyecto dentro del plazo y el presupuesto requerido. Generación Rápida de Código Productivo: La metodología RAD permite a los miembros del equipo producir rápidamente prototipos y código de trabajo, mientras que en otras metodologías que requieran de más planeación requerirían semanas o inclusive meses. Compartimento de componentes del sistema: Todos los componentes generados utilizando rapid application development deben de ser encapsulados, es decir, deben ser funcionales e independientes por sí solos, para de esta manera ser utilizados en una versión iterativa o compartido, así mismo, si se requiere realizar una modificación, no afectaría a los demás componentes. Integración temprana de sistemas: mientras que la mayoría de los proyectos tradicionales deben esperar hasta el final del ciclo de vida para comenzar las integraciones con otros sistemas o servicios, RAD se integra casi de inmediato. Al requerir integraciones tempranas dentro de un prototipo, un sistema RAD identifica rápidamente cualquier error o complicación dentro de las integraciones y fuerza resoluciones inmediatas (Powell, 2016).

13 Desventajas de RAD Requiere Sistemas Modulares: Debido a que cada componente dentro del sistema debe ser capaz de ser desarrollado en un ciclo iterativo y comprobable por sí mismo, el diseño general del sistema cuando se usa RAD requiere que cada componente sea modular, permitiendo que los elementos sean intercambiados y alterados por una variedad de miembros del equipo. Dificultad con proyectos a gran escala: Los métodos de aplicaciones de desarrollo flexible tienden a reducir el control y las restricciones, por lo que puede ser difícil manejar la flexibilidad y el alcance para aplicaciones más grandes. Demandas de interacción frecuente del usuario: Obtener información y retroalimentación del usuario temprano ya menudo es sin duda un beneficio desde una perspectiva de diseño, pero puede ser un aspecto negativo, debido a que el equipo tiene que estar dispuesto a comunicarse con el usuario más seguido, además de depende de la disponibilidad del usuario. Depende de los desarrolladores expertos: Si bien muchos desarrolladores en estos días son multidisciplinarios, vale la pena señalar que el uso de técnicas RAD requiere una mayor habilidad general en todo el equipo de desarrollo, con el fin de adaptarse rápidamente a medida que el sistema y los componentes evolucionan (Powell, 2016).

14 Desarrollo de software basado en componentes En el mercado actual, las empresas conocen el gran valor que un buen sistema de software puede agregar a su negocio, por lo que cada vez es mayor la demanda de estos y se pide más velocidad en las entregas. El desarrollo basado en componentes o DSBC intenta ayudar a solucionar esto, mediante la definición de un proceso para desarrollar sistemas nuevos reutilizando piezas de software pre-escritas. Gracias al DSBC, es posible disminuir los costos, tiempo de desarrollo e implementación y esfuerzo necesarios, para así aumentar la productividad y minimizar de forma general los riesgos. Esto se debe a que al reutilizar componentes ya conocidos, previamente probados y desarrollados para ser implementados en distintos ambientes, se cuenta con piezas de software robustas y capaces de realizar su trabajo sin importar en donde sean implementadas, mientras dicha implementación se realice de la manera correcta. Además, se trata de una metodología que por naturaleza produce software de forma evolutiva, ya que se pueden acoplar componentes al sistema para dar solución a nuevos problemas del cliente. Estadísticas de reutilización de código Existen varios indicadores que demuestran que es posible desarrollar software de calidad utilizando componentes previamente escritos, ya que muchos de los sistemas actuales comparten gran parte de su funcionalidad principal y es muy poco el código no reutilizable o de uso específico. A continuación se muestran algunos datos mencionados por Montilva et al en su investigación. (2003) Entre el 40 y 60 porciento del código fuente de una aplicación es reutilizable en otra similar. Aproximadamente el 60% del diseño y del código de aplicaciones administrativas es reutilizable. Aproximadamente el 75% de las funciones son comunes a más de un programa.

15 Sólo el 15% del código encontrado en muchos sistemas es único y novedoso a una aplicación específica. Como lo muestran los datos anteriores, el porcentaje de software potencialmente reutilizable es bastante grande, pero esto no significa que podamos utilizar ese código para otros sistemas directamente. Características de un componente Los componentes que pueden ser reutilizables deben complir ciertas características para asegurar su calidad de funcionamiento y acoplamiento en distintos ambientes. Para poder decir que una pieza de software es un componente adecuado para ser reutlizable, debe complir las siguientes características, según Mayer (1999): 1. Pueden ser usados por otros elementos de software. 2. Puede ser usado por los clientes sin la intervención de los desarrolladores. 3. Incluye la especificación de todas las dependencias. 4. Incluye la especificación de las funcionalidades que ofrece. 5. Se puede entender su funcionamiento con base en sus especificaciones. 6. Es acoplable a otros componentes. 7. Puede ser incorporado o integrado a un sistema de manera rápida y fluida. Otras características que son deseables en un componente son la posibilidad de ser reemplazado por otro componente, que permita acceso solamente por sus interfaces para asegurar que este no cambiará a lo largo de su implementación y que, en la medida de lo posible, sea independiente de la plataforma en la que pueda ser implementado. Una vez definido esto, es necesario aclarar también que, como lo mencionan Sodhi et al, la reutilización de software va más allá de la reutilización de piezas de software. Ella involucra el uso de otros elementos de software, tales como algoritmos, diseños, arquitecturas de software, documentación y especificaciones de requerimientos (1999). Por lo que es necesaria la definición de un proceso estructurado de desarrollo para lograr una correcta integración de los componentes según las especificaciones y necesidades del cliente.

16 Etapas Las etapas del DSBC propone las siguientes etapas, las cuales pretenden asegurar una correcta comprensión de las necesidades del negocio y de la obtención de los componentes necesarios para satisfacerlas. Obtención y análisis de requerimientos Como en cualquier metodología de desarrollo, el primer paso es la conversación con el cliente para conocer las necesidades que este tiene y las razones por las que desea desarrollar un sistema de software. Los requerimientos pueden documentarse mediante cualquier técnica, mientras se haga de una forma en que sean completamente claros y representen de manera fiel y completa lo que el cliente necesita. Es posible utilizar casos de uso para esto. Los requerimientos recogidos con el cliente deben ser analizados para identificar dudas o ambigüedades, aclararlas con el cliente y así obtener un conjunto de requerimientos claros. Cabe mencionar que esta es solo una lista inicial de requerimientos que brindará una idea de alto nivel de los componentes necesarios para que el sistema sea desarrollado y compla con su idea fundamental, pero el DSBC es por naturaleza evolutivo y acepta nuevos requerimientos con los que el sistema pueda obtener nuevos componentes y crecer en funcionalidad. Análisis de la arquitectura En esta etapa se define la arquitectura sobre la que se desarrollará el sistema, es decir, la estructura en la que los componentes deberán ser acoplados y la forma en la que interactuarán. Además, se debe seleccionar una arquitectura que se adecúe a las necesidades del cliente y a los componentes de software disponibles. Esta etapa es sumamente importante, ya que debe escogerse una arquitectura adecuada para que los componentes que pueden dar solución a los problemas del cliente logren ser acoplados de manera correcta. Análisis de componentes En esta etapa se busca un conjunto de componentes que logren dar solución a los problemas expuestos por el cliente. Para esto los desarrolladores deben contar de

17 antemano con un repositorio de componentes perfectamente documentados y probados. Para seleccionar estos componentes es necesario tomar en cuenta la función de cada uno de ellos, sus interfaces y los ambientes o arquitecturas sobre la que pueden trabajar. Una vez seleccionados estos componentes, es necesario identificar si alguno de ellos necesita ser modificado o tiene alguna consideración especial para ser utilizado. De no contar con un componente adecuado para cierta característica necesaria en el sistema, se deben considerar dos opciones. La primera es el desarrollo de un nuevo componente para dar solución a un problema que es específico del nuevo sistema solicitado por el cliente. Esta opción provoca que el precio final del producto de software sea mayor y el tiempo necesario para finalizar también se vea aumentado. La segunda opción es adquirir un nuevo componente de terceros. Hay empresas que se dedican al desarrollo y venta de componentes de software de calidad y capaces de adecuarse a la gran mayoría de sistemas. Un ejemplo de esto es Component Source ( quienes ofrecen más de 1900 componentes de software, además de aplicaciones completas y add-ins. Modificación de requisitos Muchas veces, la empresa desarrolladora cuenta con ciertos componentes en sus repositorios que son capaces de resolver de una u otra forma los problemas del cliente, pero no siempre lo hacen perfectamente, ya que fueron creados de forma genérica y no específica para el cliente. Por esta razón, el modelo de Desarrollo Basado en Componentes propone la posibilidad de negociar con el cliente ciertos requisitos, es decir, cambiar los requerimientos de alguna manera sin afectar las necesidades del cliente, para lograr que los requisitos se adapten a los componentes y estos puedan ser utilizados sin mayor complicación. Desarrollo de componentes En esta etapa se realiza el desarrollo de los componentes que no se lograron obtener de los repositorios ni desde otros proveedores y que se decidió desarrollar desde cero, ya que son sumamente necesarios. Es importante que los nuevos componentes desarrollados sean hechos de forma lo más genérica posible,

18 documentados de la mejor manera y agregados al repositorio de componentes, ya que podrían ser utilizados para otros sistemas en el futuro. Diseño del sistema Es necesario realizar un diseño del sistema que será desarrollado. Para esto se deben analizar los componentes seleccionados para formar parte del sistema y la arquitectura sobre la que se va a desarrollar para crear un diseño. Es necesario conocer la forma en la que cada componente trabaja, la forma en la que se comunica con otros y los datos que podría necesitar para realizar sus funciones de la forma correcta. Integración del sistema Esta es la etapa en la que se toman los componentes seleccionados para conformar el sistema, los que fueron adquiridos o los desarrollados, si fue este el caso, y se sigue el diseño elaborado comenzar a desarrollar el sistema, es decir, el acoplamiento de los componentes para crear un producto de software unificado. Pruebas integrales Se realizan pruebas en el sistema creado para garantizar que los componentes se adecuan completamente a las necesidades del cliente y que trabajan de forma correcta entre ellos para asegurar que la integración se realizó de forma correcta y exitosa. Validación del sistema Se valida el sistema desarrollado con el cliente para asegurar que es lo que realmente quiere y necesita y se explora la posibilidad de cambios en el sistema o la adición de funcionalidades extra que pueden significar la adición de un nuevo componente. De ser necesario un cambio en el sistema, se debe realizar un proceso para planear el cambio del componente que no se adecuo correctamente y rediseñar y reintegrar el sistema. Mantenimiento Se vigila el comportamiento del sistema y se corrigen errores que puedan presentarse.

19 Ventajas y desventajas Ventajas Disminuye el tiempo, costo y esfuerzo requeridos Contribuye a reutilizar software a un nivel más detallado y cuidadoso Mantenimiento mucho más fácil Facilita el proceso de pruebas Mayor retorno de la inversión o ROI Desventajas Es necesario un análisis de riesgos adecuado Puede ser muy complejo identificar y acoplar los componentes adecuados Es necesario contar con un gran repositorio de componentes El desarrollo de un componente nuevo puede significar un costo en tiempo y dinero mucho mayor del esperado En la siguiente imágen podemos observar un proceso de desarrollo utilizando el DSBC para tener una referencia visual más fácil de seguir sobre el flujo de trabajo en este modelo.

20

21 Conclusiones Ninguna metodología es mejor que otra. Cada una posee sus ventajas y desventajas. La selección de la metodología más conveniente depende del proyecto que se vaya a realizar, las necesidades del cliente o la forma en la que la empresa desarrolladora trabaja. No es bueno enfocarse solo en una metodología, aveces es bueno utilizar distintos metodos o tecnicas de otras, por ejemplo el caso de Scrumban que combina prácticas de Scrum y de Kanban, es posible también adaptar algunas metodologías predictivas a que reciban retroalimentación de los usuarios. Entonces es solo cuestión de tomar lo mejor de cada una y usarlas a conveniencia. Anexos Caso de estudio de Kanban Fuente: Caso de estudio de Rapid Application Development Fuente (Caso #1): empirical_review

22 Bibliografía Brechner, Eric.(2015). Microsoft Press Agile Project Management with Kanban. Centers for medicare & medicaid services. (2017). Selecting a development approach. [online] Available at: Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf [Accessed 30 Apr. 2017]. Chandra, V. (2015). Comparison between Various Software Development Methodologies. International Journal of Computer Applications, [online] 131(9), pp Available at: [Accessed 30 Apr. 2017]. Fuentes, L; Troya, J; Vallecillo, A. (s.f). Desarrollo de Software Basado en Componentes. [online] Available at: [Accessed 30 Apr. 2017]. Hernandez, G. (2013). Ventajas y desventajas del uso de Kanban. [online]. Available at: Kniberg, Henrik. (2009). Kanban vs Scrum How to make the most of both. Lopez,Jose.(2013).Mejora tu trabajo en equipo con el método Kanban.[online].Available at: Meyer, B. (1999). The Significance of Components. Beyond Objects column, Software Development. [online] Available at: [Accessed 30 Apr. 2017]. Monreal, C. (2014). Ciclos de vida en proyectos. Explicando algunos conceptos.. Curso Online PMP y CAPM de Dirección de Proyectos. Retrieved 4 May 2017, from Montilva, J., Arape, N. and Colmenares, J. (2003). Desarrollo de Software Basado en Componentes. [online] Available at: %20de%20componentes.pdf [Accessed 3 May 2017]. Powell A. (2016), Rapid application development: What is ts and how to used it?. [online] Available at: Sodhi, J. and Sodhi, P. (1999). Software reuse: Domain analysis and design process. 1st ed. New York: McGraw-Hill. [online] Available at: [Accessed 30 Apr. 2017].