Metodologías de desarrollo de software -...
Transcript of Metodologías de desarrollo de software -...
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].