1
UNIVERSIDAD NACIONAL DE TRUJILLO
FACULTAD DE CIENCIAS FÍSICAS Y MATEMÁTICAS
ESCUELA INFORMÁTICA
ASIGNATURA:
Ingeniería de Software II
DOCENTE:
Ms. Guevara Ruiz Ricardo Manuel
ESTUDIANTE
Morales Esquivel Christian Anthony
CICLO: VI
Trujillo, Octubre 2022
2
Modelos del proceso de ciclo de vida de software
1. Modelo en cascada
¿Qué es el modelo en cascada?
El modelo en cascada (waterfall) Éste toma las actividades fundamentales del proceso de
especificación, desarrollo, validación y evolución y, luego, los representa como fases
separadas del proceso, tal como especificación de requerimientos, diseño de software,
implementación, pruebas, etcétera (Somerville, 2011).
Las fases específicas del sistema varían entre las distintas fuentes pero, en general, incluyen las
siguientes:
1). Especificación de requerimientos
En esta etapa, debes recopilar información integral sobre lo que requiere el proyecto.
Puedes reunir esta información de distintas maneras, desde entrevistas y cuestionarios hasta
lluvias de ideas interactivas. Al final de esta fase, los requisitos del proyecto deben quedar
claros, y se debe tener un documento de requisitos que se haya distribuido en el grupo.
2). Diseño del sistema
Con los requisitos definidos, el grupo empieza el diseño del sistema. No hay ninguna
codificación durante esta fase, pero el grupo establece especificaciones, tales como el lenguaje
de programación o los requisitos del hardware.
3). Implementación
En esta fase, se hace la codificación. Los programadores toman la información de la etapa
anterior y crean un producto funcional. Generalmente implementan el código en pequeñas
porciones, las que se integran al final de esta fase o al principio de la siguiente.
3
4). Pruebas
Una vez que está listo todo el código, se puede empezar las pruebas del producto. Los
encargados de las pruebas encuentran los problemas y los informan metódicamente. Si surgen
problemas graves, el proyecto tal vez deba regresar a la fase uno para ser evaluado de nuevo.
5). Entrega / instalación
En esta fase, el producto está completo y tu equipo presenta los entregables que deberán
instalarse o lanzarse.
6). Mantenimiento
El producto es entregado al cliente y está en uso. A medida que surjan problemas, el grupo
necesitará crear parches y actualizaciones para solucionarlos. Nuevamente, si surgen problemas
graves, es posible que debas regresar a la fase uno. El mantenimiento del software debe ser
hecho periódicamente.
Figura 1
Modelo en cascada
Nota. Obtenido de (Somerville, 2011).
4
Ventajas Desventajas
Usa una estructura clara y simple por ser un Los pequeños cambios o errores que surgen
modelo lineal. en el software completo pueden causar
mucho problema.
Determina el objetivo final rápidamente. Muchas veces, sucede que el cliente no es
Adecuado para proyectos simples o muy claro de lo que exactamente quiere del
pequeños. Los requisitos se entienden bien. software. Cualquier cambio que se menciona
en el medio puede causar mucha confusión.
La documentación se produce en cada etapa La mayor desventaja del modelo de cascada
del desarrollo del modelo de cascada. Esto es una de sus mayores ventajas. No se puede
hace que la comprensión del producto diseñar volver atrás, si la fase de diseño ha ido mal,
un procedimiento más sencillo. las cosas pueden ser muy complicadas en la
fase de ejecución.
Después de cada etapa importante de la
Ningún producto funciona hasta casi la
codificación de software, las pruebas se
finalización del proyecto.
realizan para comprobar el correcto
funcionamiento del código.
Documentación extensa, con hitos claros No permite cambios de alcance. No permite
los cuales miden el progreso y muestran cambios de requisitos.
cómo se acerca a los objetivos que se han
establecido.
Fácil de manejar. Fácil de entender Incapaz de manejar fácilmente riesgos
inesperados
5
2. Modelo Incremental
¿Qué es el modelo incremental?
El modelo de desarrollo incremental es el ciclo de vida de desarrollo software en el cual un
proyecto es descompuesto en una serie de incrementos, cada uno de los cuales suministra una
porción de la funcionalidad respecto de la totalidad de los requisitos del proyecto. Los requisitos
tienen asignada una prioridad y son entregados según el orden de prioridad en el incremento
correspondiente. En algunas (pero no en todas) versiones de este modelo de ciclo de vida, cada
subproyecto sigue un “mini-modelo V” con sus propias fases de diseño, codificación y pruebas.
El modelo de gestión incremental no es un modelo necesariamente rígido, es decir, que puede
adaptarse a las características de cualquier tipo de proyecto. Existen 7 fases que debemos tener
en cuenta para implementarlo (Somerville, 2011):
1. Requerimientos:
Son los objetivos centrales y específicos que persigue el proyecto.
2. Definición de las tareas y las iteraciones:
Teniendo en cuenta lo que se busca, el siguiente paso es hacer una lista de tareas y
agruparlas en las iteraciones que tendrá el proyecto. Esta agrupación no puede ser
aleatoria. Cada una debe perseguir objetivos específicos que la definan como tal.
3. Diseño de los incrementos: Establecidas las iteraciones, es preciso definir cuál será la
evolución del producto en cada una de ellas. Cada iteración debe superar a la que le ha
precedido. Esto es lo que se denomina incremento.
4. Desarrollo del incremento:
Posteriormente se realizan las tareas previstas y se desarrollan los incrementos
establecidos en la etapa anterior.
5. Validación de incrementos:
6
Al término de cada iteración, los responsables de la gestión del proyecto deben dar por
buenos los incrementos que cada una de ellas ha arrojado. Si no son los esperados o si
ha habido algún retroceso, es necesario volver la vista atrás y buscar las causas de ello.
6. Integración de incrementos:
Una vez son validados, los incrementos dan forma a lo que se denomina línea
incremental o evolución del proyecto en su conjunto. Cada incremento ha contribuido
al resultado final.
7. Entrega del producto:
Cuando el producto en su conjunto ha sido validado y se confirma su correspondencia
con los objetivos iniciales, se procede a su entrega final.
Figura 2
Modelo incremental
Nota. Obtenido de (Teach Computer Science, 2021).
7
Ventaja Desventaja
Construir un sistema pequeño es siempre Se requiere de una experiencia importante
menos riesgoso que construir un sistema para definir los incrementos de forma de
grande. distribuir en ellos las tareas en forma
proporcional
Si un error importante es realizado, sólo la Se presupone que todos los requisitos se han
última iteración necesita ser descartada y definido al inicio.
utilizar el incremento previo.
Al ir desarrollando parte de las Si el sistema a desarrollar es de gran
funcionalidades, es más fácil determinar si magnitud y se cuenta con un único grupo para
los requerimientos planeados para los niveles construirlo se corre el riesgo que el desarrollo
subsiguientes son correctos. se prolongue demasiado en tiempo
Permite una fácil administración de las tareas El modelo Incremental no es recomendable
en cada iteración. para casos de sistemas de tiempo real, de alto
nivel de seguridad, de procesamiento
distribuido, y/o de alto índice de riesgos.
Es un modelo propicio a cambios o Requiere de mucha planeación, tanto
modificaciones. Se adapta a las necesidades administrativa como técnica.
que surjan.
La inversión se materializa a corto plazo. Requiere de metas claras para conocer el
estado del proyecto.
8
3. RUP: Proceso Unificado de Rational
El ciclo de vida organiza las tareas en fases e iteraciones. RUP divide el proceso en cuatro fases,
dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las
que se hace un mayor o menor hincapié en las distintas actividades. (Torrosi, 2018, p. 5)
Fase de Inicio
Durante la fase de inicio se desarrolla una descripción del producto final, y se presenta
el análisis del negocio. Esta fase responde las siguientes preguntas:
● ¿Cuáles son las principales funciones del sistema para los usuarios más importante?
● ¿Cómo podría ser la mejor arquitectura del sistema?
● ¿Cuál es el plan del proyecto y cuánto costará desarrollar el producto?
En esta fase se identifican y priorizan los riesgos más importantes.
El objetivo de esta fase es ayudar al equipo de proyecto a decidir cuáles son los
verdaderos objetivos del proyecto. Las iteraciones exploran diferentes soluciones posibles, y
diferentes arquitecturas posibles (Pressman, 2010).
La fase de inicio finaliza con el Hito de Objetivos del Ciclo de Vida. Este hito es alcanzado
cuando el equipo de proyectos llega a un acuerdo sobre:
● Cuál es el conjunto de necesidades del negocio, y que conjunto de funciones satisfacen
estas necesidades.
● Una planificación preliminar de iteraciones.
● Una arquitectura preliminar.
9
Fase de Elaboración
Durante la fase de elaboración se especifican en detalle la mayoría de los casos de uso del
producto y se diseña la arquitectura (Pressman, 2010). Las iteraciones en la fase de elaboración:
● Establecen una firme comprensión del problema a solucionar.
● Establece la fundación arquitectural para el software.
● Establece un plan detallado para las siguientes iteraciones.
● Elimina los mayores riesgos.
● El resultado de esta fase es la línea base de la arquitectura.
La fase de elaboración finaliza con el hito de la Arquitectura del Ciclo de Vida.
Este hito se alcanza cuando el equipo de desarrollo llega a un acuerdo sobre:
● Los casos de uso que describen la funcionalidad del sistema.
● La línea base de la arquitectura
● Los mayores riesgos han sido mitigados
● El plan del proyecto
Fase de Construcción
Durante la fase de construcción se crea el producto. La línea base de la arquitectura
crece hasta convertirse en el sistema completo.
Al final de esta fase, el producto contiene todos los casos de uso implementados, sin
embargo, puede que no esté libre de defectos (Pressman, 2010).
La fase de construcción finaliza con el hito de Capacidad Operativa Inicial. Este hito se
alcanza cuando el equipo de desarrollo llega a un acuerdo sobre:
10
● El producto es estable para ser usado
● El producto provee alguna funcionalidad de valor
● Todas las partes están listas para comenzar la transición
Fase de Transición
La fase de transición cubre el período durante el cual el producto se convierte en la
versión beta. Las iteraciones en esta fase continúan agregando características al software. Sin
embargo, las características se agregan a un sistema que el usuario se encuentra utilizando
activamente (Somerville, 2011).
Los artefactos construidos en esta fase son los mismos que en la fase de construcción.
El equipo se encuentra ocupado fundamentalmente en corregir y extender la funcionalidad del
sistema desarrollado en la fase anterior (Somerville, 2011).
La fase de transición finaliza con el hito de Lanzamiento del Producto, Este hito se
alcanza cuando el equipo de desarrollo llega a un acuerdo sobre:
● Se han alcanzado los objetivos fijados en la fase de Inicio.
● El usuario está satisfecho.
Ventajas
▪ Está basada totalmente en mejoras prácticas de la metodología:
▪ Reduce riesgos del proyecto.
▪ Incorpora fielmente el objetivo de calidad.
▪ Integra desarrollo con mantenimiento.
11
Desventajas
▪ Pretende prever y tener todo el control de antemano
▪ Modelo genera trabajo adicional.
▪ Genera muchos costos.
▪ No recomendable para proyectos pequeños
(Metodologia Rup, 2017).
Figura 3
Fases Del RUP
Nota. Adaptado de (Gracia, 2012).
4. Métodos Ágiles
Metodología Ágil
En febrero de 2001, tras una reunión celebrada en Utah-EEUU, nace el término “ágil” aplicado
al desarrollo de software. En esta reunión participan un grupo de 17 expertos de la industria del
software. Su objetivo fue esbozar los valores y principios que deberían permitir a los equipos
desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del
proyecto (Amaro & Valverde, 2007).
12
Después de esta reunión se creó The Agile Alliance una organización dedicada a promover los
conceptos relacionados con el desarrollo ágil de software y ayudar a las organizaciones para
que adopten dichos conceptos. El punto de partida es fue el Manifiesto Ágil, un documento que
resume la filosofía “ágil” (Canós, Letelier, & Penadés, 2003).
Según (Instituto Agile, 2021), los 12 Principios del manifiesto ágil son:
1. Satisfacción del cliente a través de la entrega de software temprana y continua.
2. Bienvenido a los requisitos cambiantes incluso al final del proyecto.
3. Entregue valor con frecuencia: Dividir el producto o proyecto en pequeñas partes y
desarrollarlo mediante iteraciones cortas, permite al equipo hacer entrega de
funcionalidades al final de cada sprint.
4. Con la mayor frecuencia posible, asegure la cooperación entre el equipo del proyecto y
las personas del sector.
5. Construya proyectos alrededor de individuos motivados.
6. La forma más efectiva de comunicación es cara a cara.
7. El software de trabajo es la principal medida de progreso: el objetivo de cada sprint es
producir un software que funcione, idealmente debe ocurrir dentro del plazo estimado,
esta es la mejor manera de evaluar el desempeño de un equipo.
8. Mantenga un ritmo de trabajo sostenible: metas realistas y expectativas manejables, nos
ayudarán a evitar la sobrecarga y mantener un ritmo de entrega constante.
9. La excelencia continua mejora la agilidad y la buena calidad técnica: nuestro software
o producto, no solo tiene que funcionar, sino también debe pretender ser un producto
estable de alta calidad.
10. Céntrese en la simplicidad, evitando el trabajo innecesario: Intente mantener los
procesos simples y agilizar todo el ciclo, si hace falta divida cada paso tanto como sea
necesario para que cada tarea parezca simple.
13
11. Auto organización y empoderamiento de equipos.
12. Mejorar periódicamente la eficacia del equipo ajustando su comportamiento:
mediciones no tienen por finalidad ejercer control, sino darnos una valoración del
rendimiento, que no permita hacer los ajustes necesarios para avanzar así una mejora
continua.
Principales metodologías agiles:
Crystal Methodologies
Según el diseñador de Crystal: “Crystal is a family of methodologies with a common
genetic code, one that emphasizes frequent delivery, close communication and reflective
improvement. There is no one Crystal methodology. There are different Crystal methodologies
for different types of projects. Each project or organization uses the genetic code to generate
new family members.”, [Crystal es una familia de metodologías con un código genético común,
que enfatiza la entrega frecuente, la comunicación cercana y la mejora reflexiva. No existe una
metodología Crystal. Existen diferentes metodologías Crystal para diferentes tipos de
proyectos. Cada proyecto u organización utiliza el código genético para generar nuevos
miembros de la familia] (Cockburn, 2004).
El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en
mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo definidas.
Según (Cockburn, 2004), estas políticas dependerán del tamaño del equipo, estableciéndose
una clasificación por colores, por ejemplo Crystal Clear (hasta 8 miembros), Crystal Yellow (9
a 20 miembros), Crystal Orange (21 a 50 miembros), Crystal Red (51 a 100 miembros).
De acuerdo con Cockburn, las prioridades comunes a la familia Crystal son la seguridad
en el resultado del proyecto, la eficiencia en el desarrollo y la habitabilidad de las convenciones;
Crystal hace que el equipo se dirija a 7 propiedades de seguridad: son entrega frecuente, mejora
14
reflexiva de comunicación cercana, seguridad personal (el primer paso en la confianza),
enfoque, fácil acceso a usuarios expertos y entorno técnico con pruebas automatizadas, gestión
de configuración e integración frecuente.
Roles
De acuerdo con (López, 2015):
▪ Patrocinador Ejecutivo (Executive Sponsor): es la persona que finalmente permite la
realización del proyecto. Esta persona provee el dinero necesario para la ejecución
inicial del proyecto.
▪ Diseñador Principal: esta persona deberá ser el mejor desarrollador del equipo, y quien
en principio lograría desarrollar el sistema por completo. Esta persona ayudara a los
demás miembros del equipo y servirá como un modelo para los integrantes más jóvenes.
▪ Usuario Experto: el sistema en desarrollo debería responder mejor, cuando el equipo de
desarrollo se encuentra en contacto con usuarios expertos del sistema. El valor que un
sistema puede aportar a la organización es muy importante de acuerdo a la información
que los desarrolladores lograron obtener de este tipo de usuarios.
▪ Diseñador Programador: es muy importante fusionar estos dos conceptos un
programador y sin diseño, solo lograra obtener un código lleno de errores, es importante
que esta persona del equipo presente estas características. Este produce junto con el
diseñador principal el código necesario para la ejecución del sistema.
▪ Coordinador: La persona ocupando el cargo de coordinador deberá como mínimo tomar
nota de cómo va el proyecto, planeando y verificando estado de cada sesión,
combinando toda esta información para posteriormente publicarla. El coordinador es
responsable de mantener el orden, reducir conflictos y facilitar discusiones.
15
▪ Experto en Negocios: es el experto en materia de negocio y verifica su estado. Define
que políticas o estrategias deberán mantenerse y que otras deberían cambiarse. Deberá
permanecer en contacto con los desarrolladores, realizando preguntas frecuentes sobre
la ejecución del sistema.
▪ Verificador: este papel, en grupos pequeños de trabajo por lo general son alternados
entre los diferentes miembros del equipo, cualquier miembro del equipo está en la
facultad de producir los reportes, sobre el estado del proyecto o del sistema en
desarrollo.
▪ Escritor: al igual que el verificador, este suele ser alternador por los diferentes miembros
del equipo, por lo general el papel que desempeña es de plasmar el manual de usuario
del sistema.
Figura 4
Estructura general de las metodologías cristal.
Nota. Obtenido de (Muñoz, 2017).
16
Según (Singh, 2021) las ventajas y desventajas de estas metodologías son:
Ventajas
▪ El método Crystal es flexible y puede ajustarse al tipo de proyecto, el tamaño del equipo
y los requisitos del proyecto.
▪ Se lleva a cabo la entrega prioritaria de los componentes Críticos y altamente esenciales
del proyecto.
▪ Este método promueve la comunicación efectiva del equipo y esto ayuda a los miembros
del equipo a aprender unos de otros.
▪ Por lo general, tiene un contrato de precio fijo, lo que ayuda a finalizar el plan según el
presupuesto.
Desventajas
▪ Los principios seguidos pueden variar según el equipo y el tamaño del proyecto, lo que
dificulta su comprensión.
▪ Necesita una comunicación constante, y esta es la razón por la que puede no funcionar
bien para los proyectos que tienen múltiples áreas de trabajo.
SCRUM
Según los desarrolladores de esta metodología (Schwaber & Sutherland, 2020), Scrum
emplea un enfoque iterativo e incremental para optimizar la previsibilidad y controlar el riesgo.
Scrum involucra a grupos de personas que colectivamente tienen todas las habilidades y
experiencia para hacer el trabajo y compartir o adquirir tales habilidades según sea necesario.
Scrum requiere un Scrum Master para fomentar un entorno donde:
1. Un propietario del producto (Product Owner) ordena el trabajo de un problema
complejo en un Product Backlog.
17
2. El equipo de Scrum convierte una selección del trabajo en un Incremento de valor
durante un Sprint.
3. El equipo de Scrum y sus partes interesadas (stakeholders) inspeccionan los
resultados y realizan los ajustes necesarios para el próximo Sprint.
4. Repetir
La unidad fundamental de Scrum es un pequeño equipo de personas, un equipo Scrum.
El equipo Scrum consta de un Scrum Master, un propietario de producto (Product Owner) y
desarrolladores. Dentro de un equipo de Scrum, no hay sub-equipos ni jerarquías. Es una unidad
cohesionada de profesionales enfocada en un objetivo a la vez, el objetivo del Producto.
El equipo de Scrum es lo suficientemente pequeño como para permanecer ágil y lo
suficientemente grande como para completar un trabajo significativo dentro de un Sprint, por
lo general 10 o menos personas. los equipos de Scrum se vuelven demasiado grandes, se debe
considerar la posibilidad de reorganizarse en varios equipos Scrum cohesionados, cada uno
centrado en el mismo producto. Por lo tanto, deben compartir el mismo objetivo de producto,
trabajo pendiente del producto (Product Backlog) y propietario del producto (Product Owner).
Según (Fonseca, Obregón, & Espinosa, 2017), sus principales características se pueden
resumir en dos: El desarrollo de software se realiza mediante iteraciones denominadas sprints,
con una duración de 30 días, el resultado de cada sprint es un incremento ejecutable que se
muestra al cliente. La segunda característica importante son las reuniones a lo largo del
proyecto, entre ellas destaca la reunión diaria de 15 minutos del equipo de desarrollo para
coordinación e integración.
Roles
De acuerdo con (Muradas, 2018) el equipo está conformado por:
18
▪ Stakeholder: Es el cliente, su responsabilidad radica en definir los requerimientos
(Product Backlog), recibir el producto al final de cada iteración y proporcionar el
feedback correspondiente.
▪ Product Owner: Es el intermediario de la comunicación entre el cliente (stakeholder) y
el equipo de desarrollo. Este debe priorizar los requerimientos según sean las
necesidades de la solicitud.
▪ Scrum Master: Actúa como facilitador ante todo el equipo de desarrollo, elimina todos
aquellos impedimentos que identifique durante el proceso, así mismo se encarga de que
el equipo siga los valores y los principios ágiles, las reglas y los procesos de Scrum,
incentivando al grupo de trabajo.
▪ Scrum Team (Equipo de desarrollo): Se encarga de desarrollar los casos de uso
definidos en el Product Backlog, es un equipo auto gestionado lo que quiere decir que
no existe un de jefe de equipo, motivo por el cual todos los miembros se deben de
encargar de realizar las estimaciones y en base a la velocidad obtenida en las iteraciones
irán construyendo el Sprint Backlog.
Según lo expresado por (Muradas, 2018), un pilar fundamental de esta metodología son las
reuniones, donde el equipo realiza las revisiones al proyecto; los tipos de reuniones son los
siguientes.
▪ Reunión de planificación: Se debe realizar al inicio de cada sprint, esto con el objetivo
de planificar la cantidad de trabajo a la que el equipo se va a comprometer a construir
durante el próximo sprint.
▪ Reunión diaria: Son reuniones cuyo lapso tiene un máximo 15 minutos, en ellas se
realiza una retroalimentación de qué se hizo el día ayer, qué se hará hoy y cuáles han
sido los problemas que han surgido hasta el momento. El objetivo, es que el equipo
establezca un plan para las próximas 24 horas.
19
▪ Reunión de revisión: Se lleva a cabo al final de cada sprint, en ellas se exponen los
puntos completados y los que no.
▪ Reunión de retrospectiva: Una vez culminado un sprint se efectúa esta reunión, que
tiene como objetivo que el equipo reflexione y saque como resultado posibles acciones
de mejora. A ella, debe asistir todo el Equipo Scrum (Dueño de Producto, Equipo de
Desarrollo y Scrum Master). Es una de las reuniones más importantes ya que es un
espacio de reflexión y mejora continua.
Figura 5
Metodología de Scrum
Nota. Obtenido de (Muradas, 2018).
De acuerdo con (Simpli Learn, 2022) las ventajas y desventajas de Scrum son:
Ventajas
▪ Scrum puede ayudar a los equipos a completar los entregables del proyecto de manera
rápida y eficiente.
▪ Scrum asegura el uso efectivo del tiempo y el dinero.
20
▪ Los grandes proyectos se dividen en sprints fácilmente manejables.
▪ Los desarrollos se codifican y prueban durante la revisión del sprint.
▪ Funciona bien para proyectos de desarrollo de rápido movimiento.
▪ El equipo obtiene una visibilidad clara a través de las reuniones Scrum.
▪ Scrum, al ser ágil, adopta los comentarios de los clientes y las partes interesadas.
▪ Los sprints cortos permiten cambios basados en comentarios mucho más fácilmente
▪ El esfuerzo individual de cada miembro del equipo es visible durante las reuniones
diarias de scrum.
Desventajas
▪ Scrum a menudo conduce a un avance del alcance, debido a la falta de una fecha de
finalización definitiva.
▪ Las posibilidades de fracaso del proyecto son altas si las personas no están muy
comprometidas o no cooperan.
▪ Adoptar el marco Scrum en equipos grandes es un desafío.
▪ El marco puede tener éxito solo con miembros del equipo experimentados.
Herramientas
Una herramientas Scrum es un software de gestión que ayuda a los equipos a organizar tareas
en proyectos complejos a través de iteraciones y Sprints.
Asana
De acuerdo con (Sentrio, 2022), es una herramienta web y móvil que facilita la creación, gestión
y distribución del flujo de trabajo de tareas y proyectos con el fin de conseguir la máxima
productividad en el ciclo de un proyecto desde el inicio hasta el final. Ayuda a los integrantes
del equipo a coordinar responsabilidades, organizar recursos y tiempos de entrega.
Funcionalidades de Asana
21
▪ Creación de proyectos.
▪ Creación de tableros para ver estado de tareas y plazos de entrega.
▪ Creación de cronogramas para representar los plazos de cada fase de un proyecto.
▪ Creación de calendarios donde se incluyen programación de recordatorios o fechas de
los proyectos.
▪ Integración de la información para reunir archivos o emails.
▪ Integración con otras aplicaciones
Figura 6
Interfaz de Asana
Nota. Obtenido de (Sentrio, 2022).
22
QuickScrum
Según (Sentrio, 2022), es una herramienta web muy útil y sencilla para aplicar el marco de
trabajo Scrum para la planificación y desarrollo de proyectos.
Estas son algunas de las principales utilidades:
▪ Dispone de una interfaz muy fácil de usar con la función de “arrastrar y soltar”.
▪ Incluye tableros para visualizar los flujos de trabajo.
▪ Tiene soporte para archivos adjuntos e integración de comentarios en cada ítem de
trabajo.
▪ Permite crear y estimar historias de usuario y definir Sprints.
▪ Facilita la visualización del progreso de los proyectos incluyendo gráficos de avance y
velocidad.
.Figura 7
Interfaz de QuickScrum
Nota. Obtenido de (Sentrio, 2022).
23
Programación Extrema (Extreme Programming)
Según refiere su diseñador Ken Beck, está diseñado para trabajar con proyectos que
pueden ser construidos por equipos de dos a diez programadores; además esta metodología se
distingue de las demás por sus siguientes características (Beck & Andres, 2004).
▪ Sus cortos ciclos de desarrollo, que resultan en proyectos tempranos, concretos y con
retroalimentación continua.
▪ Su enfoque de planificación incremental, que genera rápidamente un plan general que
se espera evolucione a lo largo de la vida del proyecto.
▪ Su capacidad para programar de manera flexible la implementación de la funcionalidad,
respondiendo a las cambiantes necesidades del negocio.
▪ Su confianza en pruebas automatizadas escritas por programadores, clientes y
probadores para monitorear el progreso del desarrollo, permitir que el sistema
evolucione y detectar defectos temprano.
▪ Su dependencia de la comunicación oral, las pruebas y el código fuente para comunicar
la estructura y la intención del sistema.
Ventajas de la programación extrema, según (Teach Computer Science, 2021).
▪ Rápido: Los proyectos de XP duran relativamente solo varios meses. Esto se debe al
entorno de trabajo acelerado que implementa XP, lo que reduce la cantidad de tiempo
perdido y trabaja en lo que es importante durante cada iteración. Todo esto permite una
integración y un despliegue continuos.
▪ Visible: XP permite una comunicación abierta entre los miembros del equipo y los
equipos de desarrollo, lo que permite que todos se mantengan al día con el avance y el
progreso del proyecto. Se llevan a cabo reuniones periódicas para asegurarse de que
todos conozcan sus tareas y para registrar el progreso realizado.
24
▪ Reducir costos: Debido a que XP implementa un trabajo en equipo constante y la
retroalimentación del cliente, esto permite realizar cambios cuando sea necesario y en
el menor tiempo posible. Estas alteraciones en los requisitos o cualquier nueva
modificación requerida se implementan en el período de desarrollo y no al final.
▪ Trabajo en equipo: XP tiene una influencia extremadamente fuerte en el trabajo en
equipo, lo que permite a los desarrolladores cumplir con los requisitos que se
propusieron dentro de plazos ajustados.
▪ Fuerte relación con el cliente: XP recomienda encarecidamente que el
propietario/cliente del proyecto esté disponible cuando sea necesario para que se puedan
hacer preguntas o se realicen revisiones para obtener los comentarios necesarios para
que se pueda implementar de una manera más eficiente.
Desventajas de la programación extrema, según (Teach Computer Science, 2021).
▪ El código supera al diseño: XP se enfoca demasiado en el aspecto de programación del
sistema y su importancia supera el diseño. Esto puede ser una desventaja si el sistema
en particular requiere que la estética sea una de sus características importantes.
▪ Ubicación: Los proyectos de XP funcionan mejor cuando el cliente y el equipo de
desarrollo están cerca uno del otro (en cuanto a la distancia) para que puedan
encontrarse cara a cara.
▪ Falta de documentación: No se puede ocultar que XP permite cambios constantes en el
proyecto, sin embargo, estos cambios constantes rara vez se documentan correctamente.
Por lo tanto, esto permite un alto riesgo de fallas inesperadas que no se pueden rastrear,
lo que induce un efecto dominó que inevitablemente terminará reduciendo la eficiencia
y la productividad del equipo.
25
Figura 8
Metodología XP
Nota. Obtenido de (Muradas, 2018).
5. Ciclo de vida para "aplicaciones móviles".
Hoy en día, el mercado de aplicaciones móviles se está expandiendo rápidamente a
medida que nuestra sociedad se vuelve más dependiente de los teléfonos inteligentes y la
tecnología digital, pero crear aplicaciones no es fácil. Se necesita tiempo, experiencia y, a
menudo, es costoso. Un error común que cometen las personas es saltar directamente en lugar
de tomarse el tiempo para comprender lo que quieren decir y comprender los diversos pasos
involucrados en la creación de una aplicación exitosa. Las etapas del desarrollo de una
aplicación móvil incluyen desde el presupuesto y la ideación hasta el mantenimiento de la
aplicación. En este informe, nos centraremos en cada parte de su proceso de desarrollo
1). Tener en cuenta el presupuesto para el desarrollo de la aplicación, es decir, tener en cuenta
los recursos que se van a destinar al desarrollo , en este caso partiendo del presupuesto, se podrá
26
desarrollar una aplicación móvil con mayor envergadura y con múltiples funcionalidades y otra
más sencilla
2). Objetivos: hay tres aspectos claves para el desarrollo de la aplicación móvil estos son :
producto, crecimiento, finanza; aquí es donde nos preguntamos qué es lo que va a hacer nuestro
producto, o con qué fines. Para esto se debe tener en cuenta las necesidades del usuario o el
problema a resolver. En base a estas características se definirá un concepto específico y el valor
añadido que puede aportar. Con respecto al crecimiento se enfocaría en el posicionamiento del
producto en el mercado y en finanzas más que todo influye el presupuesto.
3). La planificación nos indica que cualquier proyecto requiere una fase de planificación
estándar. Calendario de trabajo, que especifique la lista de actividades que se realizará al final
del proyecto: tiempo de desarrollo, actividades de marketing, tiendas en crecimiento o
aplicaciones de lanzamiento. Es muy conveniente advertir a los desarrolladores de la fecha de
lanzamiento requerida para coordinar la fecha de carga en la tienda.
4). Seleccionar el tipo de tecnología que queramos para la creación o desarrollo de nuestra
aplicación móvil por ejemplo podrían ser NATIVA APPS O PROGRESSIVE WEB APPS se
tendría que evaluar los pro y los contra para así decantarnos por una de las dos .
5). Opciones para la creación de “aplicación móvil ” en donde lo puede crear uno mismo , por
otro lado puede recurrir a contratar una agencia o desarrollador independiente o también utilizar
un creador de apps
6). Prueba de la creación de “aplicación móvil ” Después de todo el proceso de aplicación
(concepto, diseño y tecnología), puede iniciar la versión. Antes de compartir nuevas
aplicaciones con el mundo, haga varias pruebas para verificar si todo está planeado. Debe
probar todas las versiones (iOS, Android y/o PWA) de la aplicación que planea lanzar.
27
7).Estabilización : es el proceso de corregir errores en una aplicación. Esto debe entenderse no
sólo desde un punto de vista funcional (por ejemplo: "Se bloquea cuando presiona este botón"),
sino también desde un punto de vista de usabilidad y rendimiento. Es mejor comenzar la
estabilización al principio del proceso de desarrollo para que se puedan realizar mejoras antes
de que se vuelvan costosas. Por lo general, las aplicaciones pasan por fases de prototipo, alfa,
beta y candidatas a lanzamiento.
8).Lanzamiento: aquí básicamente se trata de realizar una estrategia a seguir , más que todo
evaluar cual es la idea de negocio , al fin de la aplicación , pero también es el momento de
definir a qué audiencia se dirigirá.
9). Mantenimiento o Implementación: Todo el software se actualiza, como el lanzamiento de
un nuevo sistema operativo, un cambio en la política de la tienda o la venta de teléfonos
inteligentes más nuevos. Por lo tanto, existe la necesidad de un proveedor que optimice y
mantenga continuamente la aplicación móvil a largo plazo después de su lanzamiento. Para
llevar a cabo cualquier proyecto, es importante contar con un buen equipo que te asesore y
asesore en todas las etapas del desarrollo de la aplicación móvil, para garantizar su calidad y
éxito. Además, es práctico para analizar y hacer un seguimiento de los resultados y la recepción
de usuarios de cara a mejoras posteriores o para optimizar la plataforma a través de
actualizaciones o incluso nuevas versiones, brindando así más beneficios a los usuarios.
A menudo, muchas de estas partes se superponen, por ejemplo, es común que el desarrollo siga
mientras se finaliza la interfaz de usuario e incluso puede afectar al diseño de la interfaz de
usuario. Además, una aplicación puede estar en una fase de estabilización al mismo tiempo que
se agregan nuevas características a una nueva versión.
Asimismo, estas fases se pueden usar en varias metodologías de SDLC como Agile, Spiral,
Waterfall, etc.
28
Referencias Bibliográficas
Amaro, S., & Valverde, J. (2007). Metodologías Ágiles. Trujillo.
Beck, K., & Andres, C. (2004). Extreme Programming Explained. Obtenido de
https://ptgmedia.pearsoncmg.com/images/9780321278654/samplepages/97803212786
54.pdf
Canós, J., Letelier, P., & Penadés, C. (2003). Métodologías Ágiles en el Desarrollo de Software.
Valencia.
Cockburn, A. (2004). Crystal clear a human-powered methodology for small teams. 313.
Fonseca, M., Obregón, E., & Espinosa, L. (2017). Metodologías Ágiles de Desarrollo de
Software. Managua.
Instituto Agile. (2021). Instituto Agile. Obtenido de https://www.institutoagile.com/post/12-
principios-del-manifiesto-%C3%A1gil
López, R. (2015). Metodologías ágiles de desarrollo de Software aplicadas a la gestión de
proyectos empresariales. 6.
Muñoz, C. (2017). Linkedin. Obtenido de https://es.linkedin.com/pulse/metodolog%C3%ADa-
%C3%A1gil-crystal-clear-cristian-mu%C3%B1oz-carvajal
Muradas, Y. (2018). Open Webinars. Obtenido de https://openwebinars.net/blog/conoce-las-3-
metodologias-agiles-mas-usadas/
Navarro, A., Fernández, J., & Morales, J. (2013). Revisión de metodologías ágiles para el
desarrollo de software. Cali.
Schwaber, K., & Sutherland, J. (2020). La Guía Definitiva de Scrum: Las Reglas del Juego.
Obtenido de https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-
Spanish-Latin-South-American.pdf
Simpli Learn. (2022). Scrum Project Management: Advantages and Disadvantages. Obtenido
de https://www.simplilearn.com/scrum-project-management-article
Singh, V. (2021). Tools QA. Obtenido de https://www.toolsqa.com/agile/crystal-method/
Teach Computer Science. (2021). Obtenido de https://teachcomputerscience.com/extreme-
programming-xp/
29
Pressman, R. S. (2010). Ingienería del software un enfoque práctico. Mexico: ISBN.
Rosciano, R. A. (2015). Desarrollo de herramienta de gestión de proyectos RUP . Madrid.
Sevilla. (2016). Lenguajes y sistemas informaticos. Obtenido de Lenguajes y sistemas
informaticos:
http://www.lsi.us.es/descargas/descarga_programas.php?id=3#:~:text=REM%20(REq
uirements%20Management)%20es%20una,Ingenier%C3%ADa%20de%20Requisitos
%20para%20Sistemas
Sommervile, I. (2011). Ingieneria de Sofware. Mexico: ISBN.
Visure solutions inc. (2022). VISURE. Obtenido de VISURE:
https://visuresolutions.com/es/alternatives/rational-
requisitepro/#:~:text=Rational%20RequisitePro%20es%20una%20herramienta,gestio
nar%20los%20requisitos%20del%20proyecto.
