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

¿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

¿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

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

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.

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: http://freekomuna.com/wp-content/uploads/2015/09/tabla_2.jpg

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

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

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.

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:http://www.tatvasoft.com/blog/top-12-software-development-methodologies-and-

its-advantages-disadvantages/

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

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á

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

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

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.

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

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

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

(https://www.componentsource.com/), 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,

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.

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.

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:https://sg.com.mx/revista/aplicando-kanban-para-recuperar-un-proyecto-

ca%C3%B3tico#.WQxSwdI1_Dc

Caso de estudio de Rapid Application Development

Fuente (Caso #1):

https://www.researchgate.net/publication/31978101_Rapid_application_development_RAD_An_

empirical_review

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: https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-

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.7-10. Available at:

https://pdfs.semanticscholar.org/e237/f9cb136f494c2bd0ce91525808c5c968b6b4.pdf [Accessed 30 Apr.

2017].

Fuentes, L; Troya, J; Vallecillo, A. (s.f). Desarrollo de Software Basado en Componentes. [online]

Available at: http://www.lcc.uma.es/~av/Docencia/Doctorado/tema1.pdf [Accessed 30 Apr. 2017].

Hernandez, G. (2013). Ventajas y desventajas del uso de Kanban. [online]. Available at:

http://kanbanuji.blogspot.com/2013/04/ventajas-y-desventajas-del-uso-de-kanban.html

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:https://hipertextual.com/archivo/2013/11/que-es-kanban/

Meyer, B. (1999). The Significance of Components. Beyond Objects column, Software Development.

[online] Available at: http://www.lcc.uma.es/~av/Docencia/Doctorado/tema1.pdf [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

https://www.cursodireccionproyectos.com/2014/11/ciclo-de-vida-en-proyectos/

Montilva, J., Arape, N. and Colmenares, J. (2003). Desarrollo de Software Basado en Componentes.

[online] Available at:

http://webdelprofesor.ula.ve/ingenieria/jonas/Productos/Publicaciones/Congresos/CAC03%20Desarrollo

%20de%20componentes.pdf [Accessed 3 May 2017].

Powell A. (2016), Rapid application development: What is ts and how to used it?.

[online] Available at:

https://airbrake.io/blog/sdlc/rapid-application-development

Sodhi, J. and Sodhi, P. (1999). Software reuse: Domain analysis and design process. 1st ed. New York:

McGraw-Hill. [online] Available at:

https://books.google.co.cr/books/about/Software_Reuse.html?id=2Q9mQgAACAAJ&redir_esc=y

[Accessed 30 Apr. 2017].