INGENIERIA DE SOFTWARE

Metodologas de desarrollo.
Parte 2

Alumno: Vanessa Itzel Herrera Martnez.

No. Control: 13121446

Ingeniera en sistemas computacionales.

Profesor: Adrin Nez Vieyra.

Introduccin
Una metodologa nos ordena, nos contiene, nos permite definir lmites. Construir
software complejo requiere un gran esfuerzo: tecnologa, dinero y sobre todo:
personas. Personas que interactan entre s, con diferentes grados de
conocimiento, con diferentes roles, con diferentes intereses. Una metodologa
propone un esquema de trabajo que nos permite entender cul es nuestro rol dentro
del proyecto, nos acerca una cierta sensacin de tranquilidad, de seguridad. Sin un
proceso no sabemos cmo comenzar y cundo terminar.
En las metodologas secuenciales, el proceso de desarrollo de software se divide
en varios pasos o fases. Cada fase tiene un conjunto de metas a cumplir. El fin de
cada fase delimita el comienzo de la fase siguiente. Aunque son normales la
superposicin de fases, estas metodologas proponen una gran fase de anlisis de
requerimientos, otra de diseo, otra de construccin y otra de pruebas donde el
alcance de cada fase es la totalidad de los requerimientos de un proyecto.
En las metodologas iterativas se divide el proyecto en entregas o iteraciones. Si
cada iteracin define un conjunto de metas a cumplir, podramos pensar que no hay
una gran diferencia con la metodologa secuencial. No obstante, cada iteracin
define como entregable un software testeable por el usuario. Entonces hay etapas
de anlisis de requerimientos, diseo, construccin y prueba en cada iteracin.
Adems, cada iteracin permite revisar y cambiar los requerimientos a resolverse.
Otra taxonoma que divide las metodologas es el grado de importancia que le dan

al proceso de desarrollo

y a las personas que ejecutan ese plan

Si bien la mayora de las metodologas contemplan tanto la serie de pasos que

conforman el proceso como qu tipo de tareas deben desarrollar las personas (en
base a sus perfiles), hay metodologas en las que el proceso est por encima de las
personas. Dicho de otra manera, "respetar el proceso garantiza el xito del
proyecto". El margen de discrecionalidad (cunto puedo salirme del libreto) es
mnimo, slo en lo operacional (en el da a da). Por eso es importante para estas
metodologas poder medir cada tarea del proyecto, sea un ejecutable o
documentacin.
Por el contrario, las metodologas orientadas a las personas consideran que stas
definen el xito o fracaso de un proyecto. Les asignan un grado mayor de decisin
en cada tarea y confan en su capacidad de resolucin de un problema antes que
en las mtricas que dan los indicadores. Esto no quiere decir que el proceso no

importe, sino que ocupa un puesto de menor relevancia en la consecucin de un

logro.

Ganar-ganar

Es una metodologa en forma espiral en donde todos los participantes

intercambian ideas con el fin de crear nuevos planes para alcanzar mayores
ganancias, la participacin de los clientes en el proceso de negociacin
ayuda al desarrollo del producto.
Es una adaptacin del modelo de espiral que se hace hincapi explcitamente
situados en la participacin del cliente en un proceso de negociacin en la
gnesis del desarrollo de productos. Idealmente, el desarrollador
simplemente preguntar al cliente lo que se requiere y el cliente proporcionara
el suficiente detalle para proceder. Por desgracia esto rara vez sucede y
negociaciones significativas entre ambas partes son necesarias para
equilibrar la funcionalidad, rendimiento, con los costos y el tiempo.
El modelo ganar-ganar deriva su nombre del objetivo de estas negociaciones.
El cliente recibe el producto que satisface la mayora de sus necesidades, y
el desarrollador trabaja para alcanzar presupuestos y fechas de entrega.
Para lograr este objetivo, el modelo define un conjunto de actividades de
negociacin al principio de cada paso alrededor de la espiral. En vez de una
sola actividad de los clientes de comunicacin las actividades se definen los
siguientes:

Identificacin de los actores del sistema.

Determinacin de las partes interesadas de "ganar" condiciones

Las negociaciones de la victoria de las condiciones de las partes

interesadas a que reconciliarlos en un conjunto de condiciones de ganarganar para todos los interesados.
Mostrar los requisitos al cliente.
Elaboracin del sistema o subsistemas y los objetivos,
restricciones y alternativas del proceso.
Evaluar las alternativas respecto a los objetivos y restricciones.
Identificar y resolver el mayor nmero de fuentes de producto y

Riesgos posibles.
Elaboracin de la definicin del producto y del proceso.
Planificacin del prximo ciclo y actualizacin de la planificacin del ciclo de
vida. Esto incluye, si es necesario, el particionamiento del sistema en
subsistemas a desplegarse en paralelo. Puede incluir, adems, la definicin
de un plan para finalizar el proyecto si ste es de riesgo demasiado alto o no
es factible.
Adems del nfasis inicial puesto en la condicin de ganar-ganar, el modelo
tambin presenta tres etapas del proceso (puntos de anclaje), que ayudan a
establecer la realizacin de un ciclo alrededor de la espiral y proporcionar los
hitos de decisin antes de que el proyecto de producto de software. Estos
son:
Objetivos del Ciclo de Vida - Define una serie de objetivos para cada actividad
de software ms importantes (un conjunto de objetivos relacionados con la
definicin de los principales requisitos de nivel de producto).
Arquitectura del Ciclo de Vida - Establece los objetivos que deben cumplirse
como la arquitectura de software se define.
Capacidad operativa inicial- Representa un conjunto de objetivos asociados
a la preparacin del software para la instalacin y distribucin, la preparacin
previa a las instalaciones del sitio, asistencia requerida por todas las partes
que utilizar o soporte tcnico del software.
Con esta breve descripcin se puede declarar que el Software de produccin
ms rpido puede facilitarse a travs de la participacin colaborativa de las
partes interesadas pertinentes adems de ser barato a travs de reproceso
y mantenimiento reducciones.

Ventajas
Minimiza riesgos del proyecto
Agrega objetivos de calidad
Desventajas
Genera mucho tiempo en el desarrollo del sistema
Resulta como un modelo muy costoso

 Requiere de mucha experiencia en la identificacin de los riesgos

Proceso Unificado (UP)

Constituye la metodologa estndar ms utilizada para el anlisis,

implementacin y documentacin de sistemas orientados a objetos.
EL proceso unificado no es un sistema cerrado, es un conjunto de
metodologas adaptables al contexto y necesidades de cada organizacin.
Su ciclo de vida es una implementacin del Desarrollo en espiral.
El Proceso Unificado es un proceso de software genrico que puede ser
utilizado para una gran cantidad de tipos de sistemas de software, para
diferentes reas de aplicacin, diferentes tipos de organizaciones, diferentes
niveles de competencia y diferentes tamaos de proyectos.
Provee un enfoque disciplinado en la asignacin de tareas y
responsabilidades dentro de una organizacin de desarrollo. Su meta es
asegurar la produccin de software de muy alta calidad que satisfaga las
necesidades de los usuarios finales, dentro de un calendario y presupuesto
predecible.
El proceso unificado cuenta con dos dimensiones:
1. Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo
de vida del proceso a lo largo de su desenvolvimiento:
Representa el aspecto dinmico del proceso conforme se va desarrollando,
se expresa en trminos de fases, iteraciones e hitos.
2. Un eje vertical que representa las disciplinas, las cuales agrupan
actividades de una manera lgica de acuerdo a su naturaleza.
Representa el aspecto esttico del proceso: cmo es descrito en trminos de
componentes del proceso, disciplinas, actividades, flujos de trabajo,
artefactos y roles.
Principales caractersticas
Forma disciplinada de asignar tareas y responsabilidades (quien hace que,
cundo y cmo)
Pretende implementar las mejores prcticas en Ingeniera de software.
Desarrollo Iterativo

Administracin de requisitos de arquitectura basada en componentes de

cambios Modelado visual de software
Verificacin de la calidad del software
El Proceso unificado es un producto de Rational (IBM).
Se caracteriza por ser iterativo e incremental, estar centrado en la
arquitectura y guiado por los casos de uso.
Incluye artefactos (que son los productos tangibles del proceso, como por
ejemplo el modelo de casos de uso
El modelo de clases
El cdigo fuente Etc.
Incluye tambin roles que desempean acciones en un determinado
momento.
Una persona puede desempear distintos roles a lo largo del proceso.
Est basado en 5 principios clave
1. Adaptar el proceso
El proceso deber adaptarse a las caractersticas propias del proyecto u
organizacin, El tamao del mismo, as como su tipo o las regularizaciones que
lo condicionen, incluirn en su diseo especfico.
Tambin se deber tener en cuenta el alcance del proyecto.
2. Balancear Prioridades
Los requerimientos de los distintos participantes pueden ser diferentes,
contradictorios o disputarse recursos limitados.
Debe encontrarse un balance que satisfaga los deseos de todos.
Debido a este balanceo se podrn corregir desacuerdos en el futuro.
3. Demostrar valor iterativamente
Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas.
En cada iteracin se analiza la opinin de los inversores, la estabilidad y calidad
del producto, y se refina la direccin del proyecto, as como tambin los riesgos
involucrados.
4. Elevar el nivel de abstraccin
Persigue el uso de elementos reutilizables tales como los patrones de software,
lenguajes 4GL o frameworks.
Desarrollo con la mente puesta en la reutilizacin del cdigo Un alto nivel de
abstraccin tambin permite discusiones sobre diversos niveles y soluciones
arquitectnicas.
5. Enfocarse en la calidad

El control de la calidad no debe realizarse al final de cada iteracin, sino en todos

los aspectos de la produccin.
El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un
grupo independiente.
El ciclo de vida organiza las tareas en fases e iteraciones.
Se divide en cuatro fases, dentro de las cuales se realizan varias iteraciones
segn el proyecto y en las que se hace un mayor o menor hincapi en las
distintas actividades.

Iniciacin
Elaboracin
Construccin
Transicin

Las primeras iteraciones (en las fases de inicio y elaboracin) se enfocan

hacia la comprensin del problema y la tecnologa, la delimitacin del mbito
del proyecto, la eliminacin de los riesgos crticos y al establecimiento de la
lnea de base de la arquitectura.
Fase de Iniciacin

Las iteraciones hacen mayor nfasis en actividades de modelado del

negocio y de requerimientos.

Fase de elaboracin

Las iteraciones se orientan al desarrollo de la lnea de base de la

arquitectura, abracan ms los flujos de trabajo de requerimientos,
modelos de negocio, anlisis, diseo e implementacin orientada a la
lnea de base de la arquitectura.

Fase de Construccin

Se lleva a cabo la construccin del producto mediante series de

iteraciones. Para cada iteracin se seleccionan algunos casos de uso,
se refina su anlisis y diseo y se procede a su implementacin y
pruebas. Se realiza una pequea cascada para cada ciclo. Se realizan
tantas iteraciones como requiera la implementacin del producto.

Fase de Transicin

Se pretende garantizar que se tiene un producto preparado para su

entrega a los usuarios.

Secciones

Seccin de Proceso
Modelado de Negocio
Requisitos

Anlisis y diseo
Implementacin
Pruebas
Despliegue
Seccin de Soporte
Gestin del cambio y configuraciones
Gestin del proyecto
Entorno

Artefactos
En cada una de sus fases de la estructura esttica realiza una serie de
artefactos que sirven para comprender mejor tanto el anlisis como del
diseo del sistema.
Fase de Inicio
Documento Visin
Especificacin de requerimientos
Fase de elaboracin
Diagramas de caso de uso
Fase de construccin
Trabaja desde cuatro vistas:
Vista lgica
Diagrama de clases
Modelo ER Vista de implementacin
Diagrama de Secuencia
Diagrama de estados
Diagrama de colaboracin
Vista conceptual
Modelo de dominio
Vista fsica
Mapa de comportamiento hardware.
Ventajas
Su uso es libre (como decir barra libre, sin condiciones).
Desventajas
Es necesario aterrizar los conceptos, lo cual puede resultar un poco difcil
para quien no tenga experiencia en el uso de procesos de ingeniera de
software.

Ingeniera Web

La ingeniera web es la aplicacin de metodologas sistemticas,

disciplinadas y cuantificables al desarrollo eficiente, operacin y evolucin
de aplicaciones de alta calidad en la World Wide Web.
La ingeniera web se debe al crecimiento desenfrenado que est teniendo
la Web est ocasionando un impacto en la sociedad y el nuevo manejo que
se le est dando a la informacin en las diferentes reas en que se
presenta ha hecho que las personas tiendan a realizar todas sus
actividades por esta va.
Desde que esto empez a suceder el Internet se volvi ms que una
diversin y empez a ser tomado ms en serio, ya que el aumento de
publicaciones y de informaciones hizo que la Web se volviera como un
desafo para los (Ingeniera del software) ingenieros del software, a raz de
esto se crearon enfoques disciplinados, sistemticos y metodologas donde
tuvieron en cuenta aspectos especficos de este nuevo medio.
La ingeniera de software basados en componente, como parte de la
plataforma inicial, orientacin a servicios de web y ms recientemente en
las arquitecturas orientados a servicios de web y ms recientemente en las
arquitecturas orientados a servicios(SQA), por el componente hereda otras
caractersticas ms all de un componente ordinarios (interfaz, contenido,
diseo arquitectnico, etc.)
Es una mezcla de mtodos:
-Diseo de procesos para la aplicacin
-Desarrollo web
-Herramientas case
-Modelado conceptual
-Diseo de modelado de datos para sistema de informacin
-Ingeniera emprica
-Herramientas y mtodos de prototipo.
-Control de calidad de sistema.

-Ingeniera de requisitos.
-Mtrico
-Gestin de proyecto.
-Mtodos, herramientas y automatizacin de prueba.
Ventajas

Es de fcil uso
Permite la comunicacin rpida y directa con una o varias personas que se
encuentre en cualquier parte del mundo, ayudando de esta manera en las
Tics
Desarrollo de diferentes proyectos y propuestas para dar a conocer dichos
proyectos a travs de la red
Ayuda en el proceso de globalizacin de las empresas, ya que permite
contactar diferentes entidades y personas en el mundo sin altos costos
Crear publicidad para que los clientes puedan acceder a productos y
servicios y tengan informacin actualizada de ellos.
Creacin de ventaja competitiva, ya que la empresa o entidad se
encontrara a la vanguardia de la tecnologa.

Desventajas
No posee muchas funcionalidades para la empresa. solo suple necesidades
de comunicacin.
No ofrece diversidad de opciones
Las fases que se deben de llevar acabo en esta metodologa son las
siguientes Por lo que respecta al proceso de autora de la aplicacin a lo
largo del proceso de autora.
Este proceso de autora est dividido en cuatro pasos o actividades:

Anlisis de Requisitos: Fija los requisitos funcionales de la

aplicacin Web para reflejarlos en un modelo de casos de uso.

Diseo Conceptual: Materializado en un modelo de dominio,

considerando los requisitos reflejados en los casos de uso.

Diseo Navegacional: Lo podemos subdividir en:

Modelo del Espacio de Navegacional.

Modelo de la Estructura de navegacin: Muestra la forma de navegar

ante el espacio de navegacin.

Diseo de Presentacin: Representa las vistas del interfaz del

usuario mediante modelos estndares de interaccin UML.

Metodologas giles

Las metodologas giles, durante una reunin en el ao 2001 en Utah

Estados Unidos, naci el trmino gil; el cual fue aplicado al desarrollo del
software, en esta reunin fueron participes 17 expertos entre ellos algunos
creadores o impulsores del desarrollo del software; dentro de su objetivo
fue disear valores e inauguraciones que debieran a los equipos permitir
desarrollar software rpidamente y que respondiera a los cambios que
pueden surgir a lo largo del proyecto. Su objetivo era dar una solucin y una
alternativa a los procesos de desarrollo de software tradicionales, los cuales
eran caracterizados por ser rgidos y dirigidos por la documentacin que se
genera en cada una de las actividades desarrolladas.

Dentro de este se encuentra el manifiesto gil; el cual nos ofrece tres

puntos importantes como:

1.
Al individuo y las interacciones del equipo de desarrollo sobre el
proceso y las herramientas; la gente es el principal factor de xito de un
proyecto software. Si se sigue un buen proceso de desarrollo, pero el
equipo falla, el xito no est asegurado; sin embargo, si el equipo funciona,
es ms fcil conseguir el objetivo final, aunque no se tenga un proceso bien
definido. No se necesitan desarrolladores brillantes, sino desarrolladores
que se adapten bien al trabajo en equipo. As mismo, las herramientas
(compiladores, depuradores, control de versiones, etc.) son importantes
para mejorar el rendimiento del equipo, pero el disponer ms recursos que
los estrictamente necesarios tambin puede afectar negativamente. En
resumen, es ms importante construir un buen equipo que construir el

entorno. Muchas veces se comete el error de construir primero el entorno y

esperar que el equipo se adapte automticamente. Es mejor crear el equipo
y que ste configure su propio entorno de desarrollo en base a sus
necesidades.

2.
Desarrollar software que funciona ms que conseguir una buena
documentacin; aunque se parte de la base de que el software sin
documentacin es un desastre, la regla a seguir es no producir
documentos a menos que sean necesarios de forma inmediata para tomar
una decisin importante. Estos documentos deben ser cortos y centrarse
en lo fundamental. Si una vez iniciado el proyecto, un nuevo miembro se
incorpora al equipo de desarrollo, se considera que los dos elementos que
ms le van a servir para ponerse al da son: el propio cdigo y la interaccin
con el equipo.

3.
La colaboracin con el cliente ms que la negociacin de un contrato;
las caractersticas particulares del desarrollo de software hacen que
muchos proyectos hayan fracasado por intentar cumplir unos plazos y unos
costes preestablecidos al inicio del mismo, segn los requisitos que el
cliente manifestaba en ese momento. Por ello, se propone que exista una
interaccin constante entre el cliente y el equipo de desarrollo. Esta
colaboracin entre ambos ser la que marque la marcha del proyecto y
asegure su xito.

4.
Responder a los cambios ms que seguir estrictamente un plan; la
habilidad de responder a los cambios que puedan surgir a los largo del
proyecto (cambios en los requisitos, en la tecnologa, en el equipo, etc.)
determina tambin el xito o fracaso del mismo. Por lo tanto, la planificacin
no debe ser estricta puesto que hay muchas variables en juego, debe ser
flexible para poder adaptarse a los cambios que puedan surgir. Una buena
estrategia es hacer planificaciones detalladas para unas pocas semanas y
planificaciones mucho ms abiertas para unos pocos meses.

Uno de los principales focos de aplicacin de las metodologas giles son

los proyectos tecnolgicos. Cada una de ellas tiene sus fortalezas y sus
debilidades, pero no son excluyentes. En cada proyecto podemos adoptar
una, o varias, en funcin de las caractersticas del propio proyecto y del
equipo.

Entre las metodologas giles ms usadas se encuentran:

SCRUM. Es un marco de trabajo que nos proporciona una serie de
herramientas y roles para, de una forma iterativa, poder ver el progreso y
los resultados de un proyecto.
KANBAN. Se basa en una idea muy simple. sta es que el trabajo en curso
(Work In Progress, WIP) debera limitarse y slo deberamos empezar con
algo nuevo cuando un bloque de trabajo anterior haya sido entregado o ha
pasado a otra funcin posterior de la cadena.
XP: Es una metodologa gil centrada en potenciar las relaciones
interpersonales como clave para el xito en desarrollo de software,
promoviendo el trabajo en equipo, preocupndose por el aprendizaje de los
desarrolladores y propiciando un buen clima de trabajo.

Ventajas

La primera y la que, a mi parecer es la ms importante, es que estas

metodologas ofrecen una rpida respuesta a cambios de requisitos a lo
largo del desarrollo del proyecto gracias a su proceso iterativo, es tan
importante realizar una buena recolecta de requisitos, como despus poder
modificarlos evitando grandes prdidas en cuanto a costes, motivacin,
tiempo
El cliente, si quiere colaborar, puede observar cmo va avanzando el
proyecto, y por supuesto, opinar sobre su evolucin gracias a las
numerosas reuniones que realiza el equipo con el cliente. Esto le da
tranquilidad.
Uniendo las dos anteriores, se puede deducir que, al utilizar estas
metodologas, los cambios que quiera realizar el cliente van a tener un
menor impacto, ya que se va a entregar en un pequeo intervalo de tiempo
un pequeo trozo del proyecto al cliente, y si ste quiere cambiarlo, solo
se habr perdido unas semanas de trabajo. Con las metodologas
tradicionales las entregas al cliente se realizaban tras la realizacin de una
gran parte del proyecto, eso quiere decir que el equipo ha estado
trabajando meses para que luego un mnimo cambio que quiera realizar el

cliente, conlleve la prdida de todo ese trabajo.

Importancia de la simplicidad al eliminar trabajo innecesario

Desventajas

Falta de documentacin del diseo. Al no haber documentacin es el

cdigo (junto con sus comentarios) lo que se toma como documentacin.
Problemas derivados de la comunicacin oral. No hace falta decir que algo
que est escrito no se puede borrar, en cambio, algo dicho es muy fcil
crear ambigedad.
Fuerte dependencia de las personas.
Falta de reusabilidad derivada de la falta de documentacin
Restricciones en cuanto a tamao de los proyectos
Problemas derivados del fracaso de los proyectos giles. Si un proyecto gil
fracasa no hay documentacin o hay muy poca; lo mismo ocurre con el
diseo. La comprensin del sistema se queda en las mentes de los
desarrolladores.

Metodologas emergentes
La programacin extrema o extreme Programming (XP) es una metodologa
formulada por Kent Beck y Ian Sommerville.
Caractersticas
Se diferencia porque pone ms nfasis en la adaptabilidad.
Software que funcione es ms importante que documentacin exhaustiva.
La respuesta ante el cambio es ms importante que el seguimiento de un
plan.

Los 4 valores de la metodologa XP

Simplicidad: Se simplifica el diseo para agilizar el desarrollo y facilitar el
mantenimiento.
Comunicacin: Para los programadores el cdigo comunica mejor cuanto
ms simple sea.
Retroalimentacin (feedback): Al estar el cliente integrado en el proyecto, su
opinin sobre el estado del proyecto se conoce en tiempo real.
Coraje o valenta: Una de ellas es siempre disear y programar para hoy y no
para maana.

Ventajas
Las metodologas emergentes motivan ms a los equipos de trabajo.
El principal beneficio del diseo orientado a objetos es que proporciona un
mecanismo
para
formalizar
modelos
de
la
realidad.
Evita malos entendidos de requerimientos entre el cliente y el equipo.
El uso del modelo orientado a objetos alienta la reutilizacin no solo del
software,
sino
de
diseos
completos.
Proporcionan mejores resultados en los proyectos de alto riesgo.
Desventajas
Problemas
derivados
de
la
comunicacin
oral.
Este tipo de comunicacin resulta difcil de preservar cuando pasa el tiempo
y est sujeta a muchas ambigedades.

Conclusin

Actualmente la transicin que estamos viviendo hacia una sociedad del

conocimiento ha cambiado profundamente las relaciones entre las personas,
empresas y gobiernos: las empresas usan la red para comunicarse con los
clientes, utilizan tambin herramientas de gestin del conocimiento para
hacer ms eficientes, los gobiernos mejoran su presencia en Internet y los
servicios a los ciudadanos a travs de la red, los usuarios usan las
herramientas para sus relaciones personales, etc. Se va de forma imparable
hacia una sociedad altamente interconectada donde el eje fundamental es la
informacin.
El desarrollo del software y la programacin es uno de los pilares
fundamentales de la informtica y al cual se dedican muchas horas de
esfuerzos en empresas, colegios, academias y universidades.
Conforme a la tecnologa va avanzando, van apareciendo nuevas soluciones,
nuevas formas de programacin, nuevos lenguajes y un sin fin de
herramientas que intentan realizar el trabajo del desarrollador un poco ms
fcil.

Con el constante desarrollo e innovacin de las tecnologas utilizadas en las

implementaciones de software, es deseable tener un modelo no dependiente
de mecanismos, mtodos y plataformas especficas, adecundolo a
necesidades y ambientes particulares.
La consideracin de un mecanismo para realizar la gestin del riesgo hace
parte de los principios tcnicos para el desarrollo de proyectos de ingeniera.
A nivel de la Ingeniera de software y del modelo planteado, la gestin acta
como instrumento para el control de calidad y como gua para conocer las
limitaciones y caractersticas del ciclo de vida.

Bibliografa

https://mdjesus.wordpress.com/2010/05/19/84/

UML y patrones, de Craig Larman, publicado por Pearson-Prentice Hall (Segunda

Edicin, Madrid, 2003).
http://gerardocuevassaucedo.blogspot.mx/2013/04/metodologias-emergentes.html
https://prezi.com/ubk9cni-o1os/metodologia-emergente/