1

Ciclos de vida y metodologías de

desarrollo de software
Jorge Aurelio Arturo De La Montaña Gutierrez Palacios
Universidad José Francisco De Caldas
Facultad Tecnológica
joagutierrezp@correo.udistrital.edu.co
Bogotá, Colombia

2020

lo tanto es un conjunto de paso o proceso conceptual basado en

RESUMEN – los temas tratados en este artículo se tienen
la finalidad de realizar una comparativa entre los ciclos de
vida y las metodologías de desarrollo de software.
Abordaremos sus conceptos, componentes, características,
ventajas y desventajas respetivamente. Así mismo
compararemos las metodologías agiles vs las metodologías
tradicionales. En la segunda parte de este artículo se
presentarán cuatro ciclos de vida de desarrollo de software,
empezaremos con la descripción de cada uno, así como
modelo, etapas, sus ventajas y desventajas. En el siguiente
apartado repetiremos esta estructura para presentar
igualmente cuatro metodologías de desarrollo de software
de las cuales dividiremos dos metologias robustas y dos
metologias agiles.
Palabras clave: ciclo de vida, modelo, metologia, fases,
artefactos.
ABSTRACT – The topics covered in this article are
intended to make a comparison between lifecycles and
software development methodologies. We will address your
concepts, components, features, pros and cons respemably.
We will also compare agile methodologies vs traditional
methodologies. In the second part of this article we will
present four software development lifecycles, we will start
with the description of each, as well as model, stages, its
advantages and disadvantages. In the next section we will
repeat this structure to also present four software
development methodologies from which we will divide two
robust methods and two agile methods.
Keywords: life cycle, model, methology, phases, artifacts.
I. INTRODUCCION
E ste documento pretende dar una introducción a los ciclos
de vida y metologias de desarrollo de software, ambos
conceptos son similares, el primero hace referencia al ciclo de
vida que tiene cada software y el otro abarca un sistema,
herramientas para el desarrollo de software. El ciclo de vida por
un determinado numero de etapas que van desde antes de iniciar
el proyecto con los estudios del problema y la viabilidad hasta
su lanzamiento y proceso de mantenimiento.
Ahora en las metodologías es importante diferenciarlas entre
lo que es un modelo, el cual se describe que hacer y las
metologias además de esto nos explican cómo hacerlo.
Teniendo más claro estos conceptos podemos añadir que los
ciclos de vida su importancia radica ya que estos nos permiten
determinar los diferentes tipos de proyectos que podemos
realizar y así aplicar la metodología adecuada, siendo así los
ciclos un modelo de qué hacer. Siendo muy útil, como veremos
en el desarrollo de articulo hay diferentes metologias y no
siempre la misma metodología puede ser viable para diferentes
problemas ya sean de la misma organización o el caso de que
un mismo problema en partícula no sería solucionado con la
misma eficiencia en dos organizaciones diferentes, esto se debe
mucho a la naturaleza de la empresa y de su entorno, como son
las herramientas, recursos tanto humanos como tecnológicos,
mercado, necesidades, tiempo disponible o requerido, aun mas
importante el presupuesto y alcance de las empresas, estos
pueden ser un obstáculo o una buena base para el desarrollo de
software.
II. PROBLEMÁTICA DEL DESARROLLO DE
SOFTWARE
En Primeramente parte un proyecto de software lo podemos
definir como un esfuerzo, trabajo temporal que se realiza para
desarrollar un producto de software o un servicio de las TI. El
software es algo que se desarrolla no se fabrica, es una
construcción a la medida, su recurso principal son las personas,
en esto último no da a entender que para acelera el proyecto
siempre sea bueno añadir mas personal puesto que esto puede
antes demorar mas el proceso mientras se hace la inclusión y
estén al tanto y al ritmo del proyecto. El software tiene
mantenimientos, a diferencias de otros productos de la industria
este no se estropee, deteriora, solo sufre cambios
(actualizaciones).

La problemática que ha surgido en el desarrollo de software
de los últimos años esta relacionado en logar la satisfacción del
cliente y a esto se le pueden sumar la comunicación y otros
factores más técnicos como él un mal manejo de tiempos,
errores planeación de riesgos, perdida de calidad, diseño no
acertado a lo solicitado, falta de capacitación, liderazgo y
motivación débil, intentar acelerar el proyecto con mas personal
entre otras, de las cuales destacare y describiré un poco más:
A. Mal estimación de tiempos
Esto puede generar muchos imprevistos y más de recursos
afectando principalmente a los clientes, siendo un factor
económico muy grave que puede hasta frenar el proyecto y
dejarlo pausado en el caso de requerir más recursos y no
tenerlos al instante, Para evitar esto, sería conveniente:
• Se recomienda rigurosas reuniones al iniciar el
proyecto o la idea del proyecto, estableciendo las
dificultades y problemas, analizar las funcionalidades,
requerimientos y establecer un cronograma de
tiempos.
• Desarrollar la documentación requerida durante el
proceso.
• Documentar los requerimientos y necesidades del
proyecto/cliente.
B. Errores planeación de riesgos
Es crucial desarrollar una buena planeación y proveer los
posibles riesgos o inconvenientes que se pueden presentar en el
desarrollo del proyecto. Los principales riesgos pueden ser:
• Riesgos relacionados a los usuarios.
• Riesgos relacionados al liderazgo en el proyecto.
• Riesgos relacionados a la ejecución del proyecto.
• Riesgos relacionados al entorno como puede ser la
competencia y el cambio del mercado.
C. Estándares de calidad
Es conveniente tener varios procesos de control de calidad en
cada etapa. Se debe realizar pruebas al finalizar o terminar las
etapas, detectando posibles errores
D. Diseño no acertado
Es posible por mala planeación o comunicación generar una
planeación no acordada a los requerimientos del proyecto o que
no cumplan con las necesidades del cliente.es necesario generar
un buen análisis en las primeras etapas, generar los receptivos
artefactos como diagramas y herramientas que puedan facilitar
esta tarea.
2
Fig. 1. Ilustración problemática del desarrollo de software por mal análisis
y comunicación.
E. Capacitación
Cada proyecto puede requerir diferentes herramientas
tecnológicas ya sean tradicionales o nuevas hasta en posible
desarrollo, para esto es indispensable que los equipos o personal
tenga tengan un amplio conocimiento y en casos necesarios
generar una retroalimentación o capacitación del personal, esto
se debe tener en cuenta en la contratación y aceptación del
personal para los equipos de trabajo.
F. Liderazgo y Motivación débil
En los equipos de trabajo dependerá mucho su
eficiencia y eficacia del liderazgo, comunicación y a su vez de
la motivación. Estas responsabilidades recaen en las manos del
líder, para estos se debe emplear estrategias que le permitan al
equipo explotar al máximo sus capacidades y creatividad sin
afectar el correcto desarrollo del proyecto.
G. Intentar acelerar el proyectó con más personal
Esto genera un gran gasto de recursos en especial el de
tiempo generando un atraso mayor si es el caso. Generando así
incluso posibles errores en el proyecto por mala comunicación,
capacitación o dirección del proyecto.
Esta problemáticas y proyecto se deben manaje con cautela,
para esto re reitera invertir tiempo y recursos en un buen análisis
y en mantener un buen equipo de trabajo, luego de esto
podemos añadir el uso de un buen modelo o metodología para
asegurar un mayor éxito de finalización. El desarrollo de
software ha evolucionado muchos aspectos del contexto y así
mismo requiere que las técnicas vallan evolucionando,
quedando una balanza entre los ciclos de vida y las
metodologías para acatar estas problemáticas.

III. DESARROLLO DE CONTENIDOS
A. Ciclo de vida de Desarrollo de software
El desarrollo de software cada vez se es más indispensable
en las organizaciones y siendo muy demandado, pero para tener
éxito es necesario llevar acabo una serie de procesos concretos.
Los ciclos de vida de Desarrollo de software son pasos
específicos y un conjunto de etapas por las cuales debe pasar y
superar un proyecto para así desarrollar un buen producto final,
aunque en algunos casos por factores inadecuados sé puede
llegar a errar.
A.1. Definición
Un ciclo de vida en el caso de los seres humanos cumple
ciertas etapas las cuales son respetivamente nacimiento,
juventud, adultez y vejez. Siendo las primeras etapas las más
delicadas pues definirán e influirán en el desarrollo de las
siguientes con el objetivo de llegar a una madurez. Siendo la
etapa inicial cuando el ser humana decide reproducirse y dar a
luz un nuevo ser comprendiéndose así entre el nacimiento y la
etapa adulta o de madurez en la cual decide general un ciclo
nuevo.
Fig. 2. Diagrama ciclos de vida humano.
El ciclo de vida Desarrollo de software comprende esta misas
etapas con el fin de llegar a la madurez de un producto de
software, esta se define como una serie de etapas o fases,
haciendo referencia a fases como el conjunto, sistema de
actividades realizadas con el fin de desarrollar un proyecto,
estas son por las que debe pasar un proyecto de ingeniería de
software desde que se esta el planteamiento del problema o idea
inicial, análisis de viabilidad hasta que es ineficiente, obsoleto
o se necesario un reemplazo, puesto que las tecnologías están
en constante cambio y evolución. Un ciclo de vida como
mencionamos es un modelo, por lo cual se compone de pasos
en los que se desarrollan tareas planificadas, cada uno de los
pasos produce una retroalimentación para el software, esto se
debe a la interactividad de los pasos para lograr una mayor
eficiencia.
3
A.2. Componentes/etapas
Este modelo en alrededor de 8 etapas, dependiendo de
cada autor, las cuales buscan cada una un tiene objetivo
especificó individual que, en conjunto formal en proyecto
final, así como una seria de actividades específicas, finalmente
siendo estas etapas:
• Expresión de necesidades: tiene el objetivo de
desarrollar el documento base del proyecto con los
requerimientos y funcionalidades.
• Especificaciones: se formaliza los requerimientos y se
toma un punto de partida.
• Análisis: se determina los elementos como
funcionalidades, descripción del producto, estructura
y factores que intervengan.
• Diseño: se determina como hacerlo, detalle de las
entidades y relaciones, base de datos.
• Implementación: codificación, desarrollo base de
datos según las etapas anteriores,
• Debugging: el objetivo es buscar todos los errores
posibles y hacer testeos.
• Validación: se verifica que el producto cumpla los
requerimientos y funcionalidades. Esto se hace en
paralelo a la etapa anterior.
• Evolución: o etapa de mantenimiento, se agregan
nuevas funcionalidades o la corrección de las
existentes.
Estas etapas cumplen la función de plantear, idear,
desarrollar, mantener el proyecto de software y se pueden
resumir en 4 principales:
Planificación
Implementación
Puesta en producción
Inicio
Control en producción
Fig. 3. Diagrama etapas ciclos de vida.

En la planificación se elabora el planteamiento de cómo
desarrollar y guiar adecuadamente y detalla el proyecto de
software, así como los gastos y recursos. En el siguiente paso,
Implementación, se elabora el acuerdo del conjunto de procesos
y actividades necesarias para la realización del producto, esto
ya depende mucho de la naturaleza del problema y los
objetivos. Ya en la etapa de definición se hace la Puesta de
producción, se presenta el proyecto al cliente o en otros casos
usuario final para verificar que cumpla los requerimientos
solicitados y cumpla el funcionamiento, aquí se deja muy caro
el proyecto para no tener contratiempos o cambios que pueden
alargar el proyecto y costos.
A estas etapas se le suman las de inicio y control, estas son
muy importantes ya que en el inicio es donde se establecen los
objeticos del proyecto, la dirección, las características tanto
implícitas como explicitas, siendo la base del proyecto y la que
implicara mucho en el éxito de este mismo.
También es muy importante tener un control de producción
mientras avanza el proyectó, verificando así que no se desfase
mucho los requerimientos, se hacen las correcciones, para esto
es muy impórtate incluir el liderazgo una amplia
documentación y capacitación para obtener un trabajo efectivo.
B. Metodología de vida de Desarrollo de software
Como hemos hecho en hincapié la ingeniería de software se
fundamenta en la prestación de servicios con altos y eficientes
estándares, por esto se enfatiza en los ciclos de vida para tener
una mayor capacidad de análisis para la solución de problemas.
Apareciendo así también las metodologías de desarrollo de
software.
B.1. Definición
La metodología la podemos definir como el grupo de
procedimientos o mecanismos para lograr un determinado
objetivo. Este término suele usarse más en las ciencias,
educación y otras áreas.
La metodología de desarrollo de software es un conjunto de
procedimientos, técnicas y métodos que permiten abortar las
actividades de los ciclos de vida en un proyecto. Su objetivo
principal es exponer varias herramientas, técnicas que permitan
desarrollar un proyecto de software de calidad. la REA la define
como, La Academia Española (2012): “Conjunto de métodos
que se siguen en una investigación científica o en una
exposición doctrinal”. Concluyendo así con cada definición
como un conjunto de pasos sistemáticos que permiten obtener
un resultado con muy buenos niveles de calidad. esta nace de la
necesidad de adaptar los sistemas informáticos existentes a las
necesidades del mercado actual, para este caso se delegaba las
tareas entre ellas la codificación, era una tarea larga y tediosa
4
poco administrada o gestionada por lo cual se generaban
muchos inconvenientes a la ora de desarrollar software. En ese
entonces era muy común la técnica muy conocida por casi todos
al ser novatos de prueba error, ir creando probando y
corrigiendo en el momento. Esto alargaba los ciclos de vida,
pues hasta no tener un proyecto eficiente y que satisfaga los
criterios del cliente se iba una vida entera y gasta de muchos
recursos. Finalmente, como hemos definido las metodologías
logran sistematizar estas tareas gestionando, administrando el
proceso para así obtener un proyecto con alto éxito.
B.2. Componentes
Siendo los procesos y componentes un factor muy importante
en las metodologías, así también en estas se definen una serie
de actividades y documentación, los cuales cumplen la función
de plantear, idear, desarrollar, mantener el proyecto de
software, las cuales son:
Fig. 4. Diagrama Componentes metodologías. Enfatiza los componentes
más importantes.
• Las Etapas/fases: Se establecen actividades y procesos a realizar
en cada fase.
• Métodos: Se descomponen los procesos en tareas pequeñas y se
define la técnica con la que se dará solución.
• Técnicas y herramientas: Se identifica como resolver cada tarea,
entre las técnicas utilizadas se encuentran:
o De recopilación de datos (entrevistas - formularios,
etc.).
o Técnicas gráficas (Diagramas).
o Técnicas de modelado (Desarrollos orientados a
objetos).
• Documentación: Se realizará la documentación de manera
minuciosa durante cada una de las fases, lo cual servirá para en
un futuro realizar la toma de decisiones acertadas para la correcta
finalización del proceso.
• Control y evaluación: Se realiza la comprobación y
admisión o denegación de los resultados obtenidos y en
caso de ser necesario, se realiza una nueva planificación.
 5

B.3.2. Ventajas vs Desventajas

B.3. Metodologías de desarrollo de software robustas o
tradicionales
TABLE I
VENTAJAS VS DESVENTAJAS METODOLOGÍAS
TRADICIONALES
B.3.1. Concepto
Ventajas Desventajas
Su base esta en una fuerte planificación y rigurosa
documentación, por lo que pueden tener algunas etapas largas. Evaluación en cada fase que La evaluación de riesgos es
En la documentación se lleva a cabo un minucioso seguimiento compleja
de cada proceso de desarrollo. Estas metodologías son Funciona bien en proyectos de Excesiva flexibilidad para
conocidas también por su desarrollo en cascada, siendo también innovación. algunos proyectos
un proceso lineal condicionando cada etapa con la anterior. De los pasos son intuitivos Dificultad al seguir un trabajo
estas metodologías robustas las más destacadas son: “Microsoft lineal
Solución Framework (MSF)”, MÉTRICA 3 y siglas de Rational los pasos intuitivos Sus etapas pueden requerir mucho
Unified Procesos (RUP). tiempo para su finalización

B.4. Metodologías de desarrollo de software Agiles

B.3.2. Características
Las metodologías tradiciones se caracterizan B.4.1. Concepto
principalmente por:
Estas metodologías son usadas para gestionar
proyectos, decisiones hasta propuestas. Con el fin de
• Primeramente, manejan 4 etapas que son:
agilizar los procesos, permitiendo una mayor flexibilidad y
una gestión eficaz. Caracterizadas por la comunicación cara,
trabajando constantemente con el cliente. Se orienta mas al
proceso y obtención del producto que la documentación,
Análisis
agilizando los tiempos. Además, esta metodología permite
realizar cambios a medida que se requieran.
Las mas destacadas de las metodologías agiles son:
Diseño
Scrum, Lean, Kanban, Extreme Programming (XP).

Codificación B.4.2. Características

Esta metodología se basa en varios principios, más

Pruebas exactamente 12, los cuales son:

Fig. 5. Diagrama etapas metodologías tradiciones.

Continuo
Feedback El clienete
• Y se caracteriza por: equipos
autonomos
es el
centro

la agilidad no
Diseño en ciclo en cascada. es sinonimo de Cambiar
rapidez, sino requisitos
de excelencia

Lineal: Inicio -a fin.

Princios
planificación Unica para todo el proyecto.
Entornos
de trabajo
sostenibles
M. Agil Acordar
Timpos de
Entrega

Definicion parámetros de control de la calidad.

La otivacion Involucrar a
es factor de todas las
exito personas
Ejecucion segun el feedback del controlling.
Informacion Motivacion
Cara a Cara del grupo
Proceso de Cierre al Finalizar el proyecto

Fig. 7. Diagrama Principios metodologías Agiles.

Fig. 6. Diagrama Características metodologías tradiciones.

Otras características importes son:
 6

Plan detallado Se trabaja sobre

• Estimula las actividades y el trabajo en equipo. funcionalidades básicas y se
• Se centra en el cliente, es considera como parte del mejora
Contratos estrictos Just in time
equipo.
Menos énfasis en la La arquitectura del software
• Entregas tempranas y continuas. arquitectura del software es esencial y se expresa
• Implementación del método Kanban, consiste en mediante modelos
medir las cantidades y el tiempo de cada proceso para
optimizar los resultados.
• Implementación método DevOps, consiste en C. Ciclo de vida de desarrollo de software
enfocarse al desarrollo de software y constante
lanzamiento de ideas.
C.1. Modelo en cascada
• Realización de un programa de actividades
• Se basa en un ciclo de vida interactivo e incremental.
En cada ciclo se repiten las etapas. Es un ciclo de vida que admite la iteración, un ciclo d vida
• Se cambia la documentación por la iteración, para secuencial como lineal, después de cada etapa se realizan
obtener una mayor eficiencia. revisiones comprobando que se puede seguir a la siguiente
etapa. Es un modelo rígido, poco flexible, fue de base para
muchos ciclos de vida. También es la versión de este modelo
B.4.3. Ventajas vs Desventajas con subproyectos, dividiendo cada una de las cascadas con
subetapas cada una independiente y desarrolladas en paralelo.
TABLE II
VENTAJAS VS DESVENTAJAS METODOLOGÍAS
AGILES C.1.1. Diagrama

Ventajas Desventajas
Especificacion
Requisitos
Definición Problema
Oportuna respuesta a cambios Alta dependencia del liderazgo
Eficiencia en la interacción de Riesgo de quedar en un ciclo de Diseño
etapas entrega
Entrega de productos más Faltas de documentación
rápido Integración Desarrollo
Eliminación de tareas Gestión rigurosa
innecesarias
Se optimizan los recursos Pruebas

Instalación
Mantenimiento
B.5. Metodologías Tradicionales vs Agiles
Mantenimient
o
TABLE III
METODOLOGÍAS TRADICIONALES VS AGILES Fig. 8. Diagrama etapas modelo ciclo de vida en cascada.

C.1.2. Descripción Etapas

Tradicionales Agiles

Realización de gran Uso de pocos artefactos, Este modelo se agrupa tus etapas en tres fases
cantidad de artefactos documentación
durante todas sus etapas. • Definición del problema, está conformada por la etapa
El cliente para la interacción El cliente es parte del equipo de especificación de requisitos y el análisis del
debe realizar una petición de de trabajo. sistema.
cita
Orientado al proceso Orientado a las personas • Desarrollo, que abarca desde el diseño,
Modelo de desarrollo Entregas incrementales e implementación hasta las pruebas del sistema.
cascada interacción continua
Es más costoso Coste en base a valor del
cliente • Mantenimiento, conformado por la instalación y el
Documentación a detalle Responsable del desarrollo mantenimiento del sistema.
exhaustivo es el equipo
Control centralizado Autoorganización Las etapas son:
predictivos Adaptable
Se define todo desde el Refactorización • Requisitos
inicio

En esta fase se hace un análisis sobre las necesidades y
requisitos que tiene el cliente, para así determinar qué
características tendrá el proyecto. Esta etapa es la de mas
cuidado pues determinará gran parte del éxito del proyecto, será
la base.
Se establece el documento de especificación de
requerimientos, los desarrolladores deben tener todo claro
desde aquí.
• Diseños
En esta etapa se describe el diseño del proyecto/producto,
las relaciones de entidades y estructura interna del software. De
aquí se desarrolla el documento SDD (Documento de Diseño
del Software).
• Integración
En este paso se programan los requisitos haciendo uso de
las estructuras de datos diseñadas en el paso anterior.
• Pruebas
Como lo indica su nombre, una vez se termina el paso de
integración se verifica que todos los componentes del sistema
funcionen y cumplen con los requisitos.
• Instalación
Una vez se han terminado todas las pruebas del software y
se ha comprobado que funcionan, Se instala la aplicación en el
sistema y se verifica que funcione correctamente.
• Mantenimiento
En la fase de mantenimiento, se debe trazar un plan para evitar
futuros conflictos con el cliente, hay que especificar cómo los
usuarios solicitarán las modificaciones o correcciones y
especificar durante cuánto tiempo se dará soporte al software.
C.1.4. Ventajas
• El fuerte análisis en las primeras etapas logra proveer
fallos generando una base más solidad para el
desarrollo del proyecto.
• La documentación es muy detallada exhaustiva y
generando una base de ayuda para un buen análisis y
comunicación entre los equipos.
• Fases bien definidas y especificadas.
• Resultados con producto de alta calidad
C.1.5. Desventajas
7
• Vista de resultados hasta etapas finales
• No apto para proyectos cambiantes o con
requerimientos no claros. Esto generar un atraso del
proyecto o un gran consumo de recursos pues al
cambiar una etapa tiene que cambiar todas las
siguientes.
• No apto para proyecto largos puesto que estos según
el entorno y mercado requerirán cambios y
modificaciones de requerimientos para esta a la
vanguardia con la competencia.
C.2. Modelo ciclo de vida V-Mode
Este modelo es una variación del modelo en cascada. El
modelo en v describe la secuencia de fases en el desarrollo del
ciclo de vida de un software. La parte izquierda del diagrama
en v representa como realizar la evolución de los
requerimientos del cliente descomponiéndolos en componentes
más pequeños. El lado derecho esta conformado por el proceso
de integración y verificación, generado en niveles sucesivos.
C.2.1. Diagrama
Fig. 9. Diagrama V-modelo. Este modelo ofrece mayor correlación de del
proyecto con los requerimientos del cliente.
C.2.2. Descripción Etapas
• Análisis
Se especificación de requerimientos, se identifican
las necesidades del cliente, también se pueden hacer
estimaciones de costos y tiempos. se determina los
elementos como funcionalidades, descripción del
producto, estructura y factores que intervengan.
• Diseño del sistema
• Diseño de la arquitectura
• Diseño de módulos
Se determina como hacerlo, detalle de las entidades
y relaciones, base de datos y se define el lenguaje
requerido.
 8

Cada mejora que añada el cliente sigue este proceso de evaluar,

• Implementación verificar riesgos e iteración, hasta que el producto llegue a un
Se inicia la codificación, creación base de datos nivel alto de satisfacción aceptado.
según los pasos anteriores.

• NIVEL 1 C.3.1. Diagrama

“El eje principal es el cliente, inicio del proyecto.
Está compuesto por el análisis de requisitos y análisis
de especificaciones, se Desarrolla el documento de
requisitos y especificaciones.

• NIVEL 2
Se centra a las funcionalidades directas e indirectas
del proyecto, se desarrolla el documento de análisis
funcionales.

• NIVEL 3
Se establecen los componentes hardware y software
del producto, este proceso es conocido como
arquitectura del sistema.
Fig. 10. Diagrama modelo en espiral.
• NIVEL 4
Es la etapa de implementación, en la que se
desarrollan los elementos unitarios o módulos del C.3.2. Descripción Etapas
programa.”
• Planificación
En esta etapa se determinan los objetivos,
C.2.4. Ventajas requerimientos principales, el alcance proyecto. En
cada iteración se aumenta el tamaño del software
entregado.
• Las etapas están relacionas entre sí. Facilitando
encontrar de errores o fallos.
• Análisis de Riesgo
• Modelo de fácil aprendizaje y sencillo de desarrollar.
La administración hace un análisis de riesgos. Se
• Hace explícito parte de la iteración y trabajo que hay
evalúa los posibles inconvenientes que pueden surgir
que revisar
en el desarrollo del proyecto. Para esto se diseñan
• Los roles están bien definidos y así las distintas prototipos que deberán ser validados en la espiral.
pruebas.
• Se Involucra al cliente en la realización de las pruebas • Implementación
Se desarrolla y valida el software según lo acordado
C.2.5. Desventajas entre el cliente y el usuario, el cual está íntimamente
relacionado y condicionado con el proyecto.
• No todos los requerimientos son fáciles de comunicar
explícitamente por el cliente. • Evaluación
Este proceso se realiza antes de dar otra vuelta a la
• Solo hasta el final del ciclo de vida se verá el producto.
espiral, se debe prestar atención a lo que sucedió en la
• En las pruebas se puede requerir un alto gasto de
vuelta anterior. Se debe analizar los riesgos detectados
recursos y pueden llegar a no cumplir con los
anteriormente y ver si ya fueron solucionados. Esta
estándares. El producto final obtenido puede que no
fase sirve para determinar el avance del proyecto y dar
refleje todos los requisitos del usuario
pistas de hacia dónde debe enfocarse la próxima
iteración.

C.3. Modelo ciclo de vida Spiral Model

C.3.4. Ventajas

Es una modificación del modelo en cascada añadiendo más

interacciones. En el cual el usuario puede cambiar de
requerimientos en cualquier momento. Suele ser muy útil
cuando se desconocen varios requerimientos se establecen los
riesgos de más bajo nivel y se comienzan con las iteraciones.
• El análisis de riesgos es muy caro y completo.
• Se reduce los riesgos del proyecto esto gracias a los
análisis anteriores.

• Cada objetivo debe tener una alta calidad así dando lo
mejor en pada vuelta.
• Integra el desarrollo con el mantenimiento para
producir una mejor experiencia al usuario.
• Además, es posible tener en cuenta mejoras y nuevos
requerimientos sin romper con el modelo, ya que el
ciclo de vida no es rígido ni estático.
C.3.5. Desventajas
• Puede durar mucho tiempo en las interacciones.
• Si hay fallos en el análisis de riesgos, se podría influir
en fallos en el resto del proyecto.
• Este modelo genera más trabajo que el resto del os
modelos mencionados.
• Al ser el análisis de riesgos una de las tareas
principales exige un alto nivel de capacitación.
C.4. Modelo ciclo de vida Modelo incremental
El modelo incremental, también conocido como el modelo de
cascada iterativa, representación tridimensional del modelo de
cascada. El eje z contiene se representa el número de iteraciones
que se. Los principales puntos fuertes de este modelo son:
• Las mejoras de las iteraciones/etapas anteriores se
pueden incorporar en la iteración actual.
• Las partes interesadas pueden participar a través de las
iteraciones, por lo que ayuda a identificar los riesgos
arquitectónicos antes.
• Facilita la entrega del producto con versiones
tempranas e incrementales que evolucionan a un
conjunto de características completo con cada
iteración.
• La implementación incremental permite supervisar los
cambios y aislar y resolver los problemas para mitigar
los riesgos.
C.4.1. Diagrama
Fig. 11. Diagrama modelo incremental.
9
C.4.2. Descripción Etapas
• Requerimientos
Se establecen los objetivos específicos y centrales del
proyecto.
• Definición de las tareas y las iteraciones
Se establecen las tareas según los requerimientos,
tipo del proyecto y las necesidades como el tiempo. Se
hace un siguiente detallado y una lista de tareas
agruparlas en las iteraciones que tendrá el proyecto.
• Diseño de los incrementos
Se asignan las iteraciones que tendrá el proyecto,
definir la evolución del producto en cada etapa e
interacción. Esto es le llama incremento.
• Desarrollo del incremento
Luego de pasar estas etapas se realizan las tareas
previstas y se desarrollan los respetivos incrementos
previamente establecidos.
• Validación de incrementos
Al avanzar, terminar cada iteración, los encargados
de la gestión deben dar los incrementos que cada etapa
ha arroja. Si no son los esperados o tiene fallos
verificar si ha habido algún retroceso o si es necesario
volver la etapa anterior.
• Integración de incrementos
Luego de validar los incrementos se va dando
forma a lo que se le llama línea incremental o la línea
de evolución del proyecto.
• Entrega del producto
Cuando el producto en su mayor parte haya sido
validado y se confirma su correspondencia con los
objetivos iniciales, se procede a su entrega final.
C.4.4. Ventajas
• Se trabaja rápido, software rápido, eficiente y en
etapas iniciales del ciclo.
• Es un modelo flexible, reduce el coste en el cambio de
alcance y requisitos.
• Facilidad al hacer revisiones y pruebas.
• Facilidad gestionar riesgos.
• Cada iteración es un hito gestionado fácilmente
C.4.5. Desventajas
• Cada etapa en las iteraciones es rígida y no se
superponen con otras.
• Posibles problemas de arquitectura por falta de
requerimientos.

D. Metodologías de desarrollo de software Robustas
D.1. Metodología en Cascada
D.1.1. Modelo
Requerimientos del sistema.
Requerimientos del software.
Análisis.
Diseño del programa.
Codificación
Pruebas.
Implantación.
Fig. 12 Metodología en cascada.
D.1.2. Etapas
Análisis
• Estudio de viabilidad: Se genera un estudio
financiero y de requisitos.
• Definición de requisitos: Se realiza una
descripción detallada de los procesos y
actividades para el desarrollo del proyecto.
• Análisis de definición de requisitos: Se
realiza un análisis de riesgos dividiendo los
riegos y problemas buscando soluciones con
subtareas pequeñas para tener una mayor
eficiencia.
Diseño
Según el paso anterior se establecen estrategias de
solución según los parámetros definidos ya, como
exigencias, viabilidad, tareas. Desarrollo del diseño de
la arquitectura de software, creación “borrador” de lo
que será el diseño de software final del producto.
Codificación
Se realiza el proceso de programación, los pasos
anteriores son traducidos al lenguaje de programación.
Cada componente se comprueba por medio de pruebas
unitarias que finalmente se integran en el resultado del
proyecto.
Integración del software
Se produce la distribución de la versión beta
enfocada a los usuarios finales, esto con el fin de
determinar errores y posibles mejoras del producto
10
antes de la implementación de su versión final.
Implantación y mantenimiento
Al realizar las etapas de pruebas con satisfacción y
ya se hallan corrección de errores, se procede a la
liberación del producto de software. Se ejecuta la
entrega, mantenimiento y mejora del producto.
D.1.3. Actividades
Gestor de • Se Gestiona y controla el proyecto durante
proyectos todas sus etapas.
Arquitecto de • Buscan solución a una problemática y se encuentran
software en la fase de especificación y obtención de requisitos.
• Realiza las pruebas, desarrollo y mantenimiento del
Desarrolladores software a partir de las indicaciones dadas por el
arquitecto de software.
• Realizan pruebas con el fin de comprobar el
Probadores funcionamiento del software anteriormente
desarrollado.
Consejeros • Experto que identificara los factores necesarios para dar solución a
las diferentes problemáticas que se puedan presentar.
Fig. 13 Modelo en cascada - Actividades.
D.1.4. Entregables
• Requerimientos de stakeholders.
• Atributos de los requerimientos.
• Documento de visión.
• Especificación de requerimientos de software.
• Modelo de casos de uso.
• Documento de arquitectura.
1. El Product Backlog
Es una lista −ordenada por valor,
riesgo, prioridad y necesidad− de los
requerimientos que el dueño del producto
define, actualiza y ordena. La lista tiene como
característica particular que nunca está
terminada, pues evoluciona durante el
desarrollo del proyecto.
2. El Sprint Backlog
Es un subconjunto de ítems del
Product Backlog y el plan para realizar en el
Incremento del producto. Debido a que el
Product Backlog está organizado por prioridad,
el Sprint Backlog es construido con los
requerimientos más prioritarios del Product
backlog y con aquellos que quedaron por
resolver en la iteración anterior.
 11

D.1.5. Herramientas Se realiza una0020documentación de cómo debería ser el

• GitHub. Repositorios, ordenador y crear trabajos de
equipos, divide el trabajo por ramas y estas con
incorporadas al pasar por una revisión.
• GitLab. Repositorios, ordenador y crear trabajos de
equipos, divide el trabajo por ramas y estas con
incorporadas al pasar por una revisión.
• Atlassian Jir: Herramienta para la planificación y
organización del trabajo, actividades, etapas y
tiempos.
• Asana: Permite visualizar mejor los objetivos, mejorar
la comunicación y colaboración en equipo, asignar
tiempos y prioridades.
• Draw: programa para crear y desarrollar diagramas
D.1.6. Ventajas
• Planificación sencilla.
• Alta calidad del producto final.
• No necesita de un personal altamente calificado.
• Fácil de comprender y manejar.
D.1.7. Desventajas
juego viéndolo desde la perspectiva del jugador.
Biblia del arte y la historia (Análisis)
Se especifican herramientas a utilizar. Se define historia y
diseño del juego.
Especificaciones técnicas (Diseño):
Se realizan diagramas y el planteamiento del código que se
debe utilizar.
Construcción (Implementación):
Se da inicio a la codificación de cada una de las partes que
conforman el videojuego (texturas, niveles, arte, modelos, etc.).
Aseguramiento de calidad (Prueba):
Se verifica que todos los componentes de videojuego
funcionen correctamente. Durante este proceso se realizan dos
fases:
• Pruebas de juego:
Hacen parte directivos y directores, quienes
mostraran el juego y realizaran una retroalimentación.
• Pruebas alfa:
Se liberan las primeras betas del juego con el fin de
buscar posibles mejoras o cambios a realizar.

• Para su correcto funcionamiento debe tener todos los D.2. Metodología RUP
requisitos planteados desde el primer momento.
• Al ser secuencial el proceso de corrección de errores La metodología RUP o “Rational Unified Process” que en
se dificulta. español significa Procesos unificados racionales, es otra
• En caso de encontrar errores al final del proceso se metodología particular de la Tradicional. El RUP surge de la
deberá gastar todos los recursos de nuevo. unión y mejora de otras metodologías principalmente por el
• Es una metodología costosa y lenta. método espiral. Basándose en marcos de procesos de trabajo
que tenga la flexibilidad de ser modificados por las empresas,
D.1.8. Ejemplo encargados en el desarrollo, se centra en la arquitectura y es
dirigido por casos de uso (los cuales son los artefactos
TABLE IV
principales para asignar el comportamiento del sistema)
Cronograma Ejemplo Metodología en Cascada también se caracteriza que es guiado por los riesgosos y es
interactivo. [8]
Cronograma Cascada
Actividad Semana
1
Semana
2
Semana
3
Semana
4
Semana
5
Semana
6
Semana
7 D.2.1. Modelo
Requerimientos              

Análisis              

Diseño               Requerimient
evaluacion
os
Codificación              

Pruebas              

Implantación              

Para este caso se basó en la planificación del desarrollo de un

software para Video Game, el cual tiene que pasar por las analisis y
prueba implementaci
etapas de planteamiento, análisis, diseño, implementación, on
pruebas y liberación, en las cuelas se desarrollarían así:

Especificación del juego (Planteamiento) Fig. 14 Metodología en RUP


D.2.2. Etapas
Inicio
En esta fase se realizan los objetivos y alcance del proyecto,
establecen los requerimientos para el usuario.
Artefactos: documento visión, especificación.
Elaboración (Arquitectura Sistema)
Su objetivo es reducir los costes y riesgos. Se crea una
estructura de lo que se puede hacer para tener un punto de
partida para luego encargarse del diseño, implementación y las
pruebas. Se construyen versiones ejecutables para entender
cómo se va a construir.
Artefactos: Diagramas caso de uso.
Fase de construcción:
Se basa en las estructuras anteriores, ya en esta fase se crea
D.2.5. Herramientas
versiones del software beta totalmente funcionales para
verificar si cumplen con las necesidades de los usuarios.
Artefactos: Documento arquitectura: diagramas,
modelos.
Transición:
En esta fase se verifica el software en su totalidad,
comprobando si cumple las especificaciones y se procede hacer
un feedback para ajustar el software y entregarlo al usuario. [8]
D.2.3. Actividades
D.2.6. Ventajas
Fig. 15 Etapas Actividades Metodología en RUP
D.2.4. Entregables
D.2.7. Desventajas
• Modelado del negocio: documento visión,
especificación
En el modelado de negocio sirven como entradas y
hacen referencia para los requisitos necesarios en el
software.
• Requerimientos:
Son necesarios para capturar y definir las
capacidades del software.
• Análisis y diseño del sistema: Diagramas caso de uso.
12
Dan información para la solución y obtención de los
requisitos requeridos y anteriormente ya establecidos.
• Implementación: Documento arquitectura:
diagramas, modelos
En estos queda la información de las soluciones
implementadas en la realización del análisis y diseño.
• Pruebas:
En este caso son los productos desarrollados en las
pruebas en la evaluación, estaban documentadas según
el responsable y actor junto con la información de las
evaluaciones realizadas y las metodologías aplicadas.
• Despliegue:
Son la documentación de los hilos del o seguimiento
el sistema y del ambiente de producción. [8]
• GitHub. Repositorios, ordenador y crear trabajos de
equipos, divide el trabajo por ramas y estas con
incorporadas al pasar por una revisión.
• GitLab. Repositorios, ordenador y crear trabajos de
equipos, divide el trabajo por ramas y estas con
incorporadas al pasar por una revisión.
• Atlassian Jir: Herramienta para la planificación y
organización del trabajo, actividades, etapas y
tiempos.
• Asana: Permite visualizar mejor los objetivos, mejorar
la comunicación y colaboración en equipo, asignar
tiempos y prioridades.
• Draw: programa para crear y desarrollar diagramas
• Se enfoca en mejorar las prácticas de las
metodologías
• Reduce muchos riesgos y se enfoca en la calidad.
• Incorporar el mantenimiento y mejoras del proyecto.
• Reduce el tiempo al aplicar la metodología RUP Y
UML
• Es un método complejo y pesado
• No es recomendado para proyectos pequeños.
• Gasto de muchos recursos y tiempo.
 13

• D.2.8. Ejemplo • E.1.2. Etapas

TABLE V
Cronograma Ejemplo Metodología en RUP Inicio
Etapa más importante, se genera el planteamiento del
Cronograma problema. En la visión el encargado debe seguir los siguientes
Actividad Semana Semana Semana Semana Semana Semana
ítems:
1 2 3 4 5 6
Inicio             • Acuerdo de entendimiento
• Levantamiento de requisitos
Elaboración            
• Verificación de requisitos
Construcción            
Planificación
Transición             En la planificación es una de las más largas, puesto que contiene
la mayor parte del análisis y se subdivide en:

• Realizar casos de uso

Uno de los ejemplos de esta metodología con gran éxito es • Verificación
el del proyecto es en argentina con el “MAFRE” implementado • Realizar diagrama de clases
por la empresa Information Technology Consulting en • Realizar el MER (Modelo entidad relación)
Argentina en el 2011. • Realizar Diagramas de actividades
• Realizar Diagramas de secuencia
También está el proyecto “ASI” con la empresa • Realizar Diagrama de despliegue
“Consultores desarrolló el sistema de Control Unitario de • Realizar Diagrama de procesos [9]
Mercancías (CUM)” en el 2009, este proyecto creó una
aplicación para gestionar eficientemente las mercancías, Desarrollo
denominadas Big Ticket, para sus tiendas y bodegas, orientadas Todos los procesos, archivos, diagramas pasan a la
a objetos basadas en la metodología RUP logrando ampliar los etapa de desarrollar y verse reflejado en el código,
horizontes, automatizando Sistemas. analizando los lenguajes, entornos y herramientas para
tener costos más bajos y hacer el proyecto viable.

• Metodologías de desarrollo de software Agiles Estabilización

• E.1. Metodología MSF
La MSF la cual significa Microsoft Solutions Framework,
es una metodología muy útil para empresas pequeñas,
mostrando los impactos tanto negativos como positivos en el
proceso de mejoramiento. Se caracteriza principalmente por ser
adaptable, es escalable, es decir puede crear equipos pequeños,
es flexible puede usarse para desarrollo de cualquier tipo de
cliente y lo mejor puede ser utilizar cualquier tecnología en su
desarrollo. [9]
• E.1.1. Modelo
En esta etapa se realizan las pruebas del software y
sacar resultados de los procesos anteriores, verificando si
cumple las especificaciones. Esta etapa para hacer la
verificación tiene 2 subprocesos:
Planificación: documentación de cómo se ejecutará las
pruebas.
Bugtracker: Se realiza para verificar los fallos, errores
posibles del proyecto, haciendo una retroalimentación.
Liberación
En esta etapa se finalizan todos los procesos, aquí queda
el software para librar y planeación de las actualizaciones,
este proceso para ser seguro y dar buena calidad al proyecto
se divide en.

• Analizar nuevos procesos

• Análisis de personal extra
• Matriz de impacto
Visión Planificación Desarrollo Estabilidad Liberación
• Lista de chequeo de contingencias
• Capacitar al usuario final

Fig. 16 Diagrama Metodología MSF

 14

• E.1.3. Actividades

Fig. 18 Herramienta Metodología MSF

Fig. 17 Diagrama Actividades Planeación Metodología MSF

E.1.4. Entregables
• Acuerdo de entendimiento: se establecen las áreas de
usuarios, gerente, responsables de dichas áreas,
impactos legales, fechas.
• Levantamiento de requisitos: como lo dice el nombre
es el documento que contiene y especifícalos
requerimientos, el cual debe ser detallado, claro y
conciso.
• Verificación de requisitos: este documento puede ser
una encuesta, verificando que se cumplan y se llegue
a una alta satisfacción.
E.1.6. Ventajas
• Crea una capa de análisis de riesgos la cual sigue
evaluando con el desarrollo del proyecto.
• Facilidad para dar soporte al proyecto y actualización.
• Es flexible, sirve tanto para pequeños y grandes
proyectos.
• Genera trabajo en equipo.
• Reutilización de ciclos anteriores.
• Está enfocado al usuario.
• Enfocado a grupos de trabajos pequeños.
E.1.7. Desventajas

• Diagrama de clases: se realizan los diagramas de clase • Necesita de demasiada documentación.

del proyecto, para generar una idea clara al siguiente • Puede gastar mucho tiempo en el análisis de riesgos.
equipo de desarrollo. • Al ser de Microsoft requiere de permisos y licencias
[9]
• MER (Modelo entidad relación): diagrama base,
requiere de mucho tiempo y análisis pues de este E.1.8. Ejemplo
documento dependerá muchos procesos, en especial la TABLE VI
base de datos. Cronograma Ejemplo Metodología en MSF

• Diagramas de actividades: cronograma, organizar Cronograma MSF

actividades. Así tener una visión clara del flujo de
Actividad Semana Semana Semana Semana Semana Semana
trabajo a realizar posteriormente. 1 2 3 4-5 6 7
Visión            
• Diagramas de secuencia: herramienta para el equipo
de ingenieros en software, aclarando herramientas Planificación            
claves.
Desarrollo            

Otros entregables son: Estabilidad            

• Diagrama de despliegue: Liberación            

• Diagrama de procesos [9]

E.1.5. Herramientas E.2.1. Metodología Scrum Manager

Actualmente Microsoft Solutions Framework es una Metodología ágil caracterizada por un desarrollo en
herramienta usada por muchas compañías y personas, puesto incremental, alta calidad en sus resultados, uso de interacciones.
que muchas de las herramientas que ofrece en los sistemas
operativos Windows, ofreciendo guías y archivos para un mejor
manejo y guía de esta metodología.
 15

E.2.1. Modelo • Supervisar y controlar el trabajo del proyecto.

• Control integrado de cambios.
• Cerrar el proyecto.”

E.2.4. Entregables y Ejemplo

Fig. 19 Metodología Scrum

E.2.2. Etapas

• Etapa Pre-Game: esta etapa se subdivide en dos, las

cuales son:
o Planificación: definición del sistema, lista Fig. 20 Artefactos Metodología Scrum
atrasos, requisitos cliente, organización
equipos de trabajo, evacuación de riesgos. • En la pila de productos se hacen la lista de
requerimientos, según la visión del proyecto.
o Arquitectura o Diseño: planificación del
sistema, funcionalidades, inclusión de
cambios, reunión de revisión de diseño, se
desarrollan panea para la liberación.

• Etapa The development: suelen aquí surgir los

imprevistos como son el atraso, calidad, requisitos.
entre otros. Esta parte es adapta y flexible sufriendo
cambios el proyecto en su transcurso. Ara realizar cad Fig. 21 ejemplo planeación Metodología Scrum
incremento en los sprint se desarrollan metodologías
tradicionales, (requisitos, análisis, diseño y • Pila Sprint se realiza una lista de trabajo, tareas por
evolución). equipos, generando un incremento.
• Etapa The Post-Game: en esta etapa se realiza el
lanzamiento, cierre del producto, esta etapa puede
contener más artículos que las anteriores. Aquí ya todo
esta listo para el lanzamiento, se realizan pruebas y
revisiones y la documentación de estas.

E.2.3. Actividades

• “Desarrollar el acta constitutiva del proyecto (Project

Charter).
• Desarrollar el enunciado del alcance preliminar
(Preliminary Scope statement). Fig. 22 Ejemplo Cronograma Metodología Scrum
• Desarrollar el plan de gestión del proyecto (Project
Management plan). • Los incrementos son resultados de la etapa de sprint.
• Dirigir y gestionar le ejecución del proyecto.

Otro artefacto es el diagrama Burn Down, sirve para comprobar
el avance del proyecto diariamente.
Fig. 23 Artefactos Metodología Scrum
Fig. 24 Crongrama Metodología Scrum
E.2.5. Herramientas
• GitHub. Repositorios, ordenador y crear trabajos de
equipos, divide el trabajo por ramas y estas con
incorporadas al pasar por una revisión.
• GitLab. Repositorios, ordenador y crear trabajos de
equipos, divide el trabajo por ramas y estas con
incorporadas al pasar por una revisión.
• Atlassian Jir: Herramienta para la planificación y
organización del trabajo, actividades, etapas y
tiempos.
• Asana: Permite visualizar mejor los objetivos, mejorar
la comunicación y colaboración en equipo, asignar
tiempos y prioridades.
E.2.6. Ventajas
• Resultados en poco tiempo
• Flexibilidad, adaptable
• Cambio de requerimientos en cualquier momento
• Trabajo en equipo
• Solución rápida de problemas en equipo
• Proceso de gestión ligero
16
E.2.7. Desventajas
• Planificación no adecuada en tiempos
• Planificación no adecuada en gastos y recursos
• No hay estimación real del tamaño final del producto
• Falta de documentación y retroalimentación
• Pueden encontrase requerimientos ambiguos
• Los cambios de requerimientos en altas etapas del
proyecto pueden generara sobre costos muy altos.
IV. CONCLUSIÓN
Las metodologías y modelos con el paso del tiempo han sido
modificados por la constante evolución del software, para así
para solución a los problemas de desarrollo de software que
principalmente se basan en la comunicación, así mismo para
cada empresa según su naturaleza y necesidades puede optar
por un determinado modelo o metodología para cumplir sus
necesidades y realizar un proyecto con alto éxito.
Podemos añadir que los ciclos de vida su importancia radica
ya que estos nos permiten determinar los diferentes tipos de
proyectos que podemos realizar y así aplicar la metodología
adecuada, siendo así los ciclos un modelo de qué hacer. Siendo
muy útil, como veremos en el desarrollo de articulo hay
diferentes metodologías y no siempre la misma metodología
puede ser viable para diferentes problemas ya sean de la misma
organización o el caso de que un mismo problema en partícula
no sería solucionado con la misma eficiencia en dos
organizaciones diferentes, esto se debe mucho a la naturaleza
de la empresa y de su entorno, como son las herramientas,
recursos tanto humanos como tecnológicos, mercado,
necesidades, tiempo disponible o requerido, aun mas
importante el presupuesto y alcance de las empresas, estos
pueden ser un obstáculo o una buena base para el desarrollo de
software.
TABLE VII
Cuadro Comparativo Metodologías Tradicionales vs Agiles
Comparación Metodologías
Tradicionales Agiles
Etapas Rígidas Etapas Flexibles
Se implementas menos los Uso de Roles. Alto
Roles Liderazgo
Excelente para proyectos Excelente para proyectos
largos cortos o rápidos
Productos hasta etapas Posibilidad de ver
finales estimaciones del Producto
en etapas tempranas
Los requerimientos tienen Los requerimientos pueden
que estará bien definidos al ser cambiados y añadidos en
inicio del proyecto cualquier etapa
Los tiempos son casi Los tiempos varían mucho
acertados según las iteraciones y los
cambios. No hay estimación
exacta de tiempos
 17

Los costos pueden ser Por los diferentes cambios y https://www.academia.edu/40414977/Mapas_Conceptuales_M

definidos claramente al
inicio del proyecto
Documentación detallada en
cada etapa
Planificación de riesgos
Diseño flexible y entendible,
modelos, diagramas.
REFERENCES
flexibilidad los costos son
inciertos y pueden aumentar
en gran medida al hacer
cambios en etapas finales
pues generan un gran coste
de recursos.
Poca documentación, se
cambia esto centrándose ene
le trabajo y avance del
producto.
Planificación adaptiva
Diseño simple y [11] C. Villarreal, "7 errores comunes en proyectos de
documentación mínima.
etodolog%C3%ADas_de_Desarrollo_de_Software. [Último
acceso: 16 Mayo 2020].
[9] A. Bravo, «Prezi,» Prezi, 09 Octubre 2013. [En línea].
Available: https://prezi.com/rcxjqpqvp7gl/microsoft-solutions-
framework-msf-es-una-metodologia-desar/. [Último acceso: 16
Mayo 2020].
[10] "Qué es SCRUM", Proyectos Ágiles, 2020. [Online].
Available: https://proyectosagiles.org/que-es-
scrum/#:~:text=Scrum%20es%20un%20proceso%20en,resulta
do%20posible%20de%20un%20proyecto. [Accessed: 06- Jul-
2020].
desarrollo de software - Northware", Northware, 2020.
[Online]. Available: https://www.northware.mx/2016/01/04/7-
errores-comunes-en-proyectos-de-desarrollo-de-software/.
[Accessed: 05- Jul- 2020].
[12] Material de Apoyo Clase Análisis de Sistemas, 2020.
[Online]. Available: Ondrive. [Accessed: 05- Jul- 2020].
[13] TOGAF 9:The Open Group;
http://www.opengroup.org/togaf/.

[1] Laboratorio Nacional de Calidad del Software,

INGENIERÍA DEL SOFTWARE: METODOLOGÍAS Y
CICLOS DE VIDA, vol. 1.0, L. N. d. C. d. Software, Ed.,
Madrid: Instituto Nacional de Tecnologías de la Comunicación,
2009, pp. 26-35.
[2] S. McConnell, «Wikipedia,» Wikipedia, 18 Junio 2004.
[En línea]. Available:
https://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_requisit
os. [Último acceso: 12 Mayo 2020].
[3] P. Domínguez, «open class rooms,» open class rooms, 6
Febrero 2020. [En línea]. Available:
https://openclassrooms.com/en/courses/4309151-gestiona-tu-
proyecto-de-desarrollo/4538221-en-que-consiste-el-modelo-
en-cascada. [Último acceso: 12 Mayo 2020].
[4] M. Ortega, «Slide Share,» Ortega, Melissa, 16 Abril
2012. [En línea]. Available:
https://es.slideshare.net/MelissaOrtega5/modelo-v. [Último
acceso: 13 Mayo 2020].
[5] D. Gutierrez, «Asp Gems,» Asp Gems, 21 Marzo 2019.
[En línea]. Available: https://aspgems.com/metodologia-de-
desarrollo-de-software-ii-modelo-de-diseno-iterativo/. [Último
acceso: 13 Mayo 2020].
[6] S. Medina, «Asp Gems,» Asp Gems, 05 Abril 2019. [En
línea]. Available: https://aspgems.com/metodologia-de-
desarrollo-de-software-iii-modelo-en-espiral/. [Último acceso:
13 Mayo 2020].
[7] J. Bautista, «Ingenieria de Software Mexico,» Ingenieria
de Software Mexico, 16 Junio 2018. [En línea]. Available:
http://ingenieriadesoftware.mex.tl/images/18149/PROGRAM
ACI%C3%93N%20EXTREMA.pdf. [Último acceso: 16 Mayo
2020].
[8] V. Diaz, «ACADEMIA,» ACADEMIA, 18 Junio 2019.
[En línea]. Available: