1.
1 Ingeniería de software
Ejemplo 1: Desarrollo del uso económico con metodología inteligente (scrum)
El banco desea desarrollar una cuenta bancaria de aplicaciones móviles, transferencia y
gestión de pagos. El equipo utiliza la metodología Scrum para garantizar el desarrollo
eficiente y personalizado con los requisitos del usuario. Los equipos multidisciplinarios están
hechos con programadores, diseñadores y analistas de negocios. El proyecto Sprint de dos
semanas se divide mejorando el software funcional en cada iteración. Las herramientas
informales y las pruebas automatizadas se utilizan para garantizar la calidad del código. La
integración continua le permite registrar errores tempranos y garantizar la estabilidad del
sistema. Este enfoque optimiza los tiempos de desarrollo y le permite comenzar un uso
estable y seguro.
1.2 El proceso y el producto de software
Ejemplo 1: Desarrollo del uso económico con metodología inteligente (Scrum)
Un banco desea desarrollar una aplicación móvil para la gestión de cuentas bancarias,
transferencias y pagos. Para ello, el equipo de desarrollo implementa la metodología Scrum,
lo que permite un enfoque ágil y colaborativo en la construcción del software.
Procesos de software: Se emplea un desarrollo incremental con sprints de dos semanas, lo
que permite la entrega continua de software funcional y mejoras iterativas.
Modelo de madurez: La aplicación de CMMI permite evaluar la calidad del desarrollo y
establecer mejores prácticas para la optimización del proyecto.
ISO [Link] Se implementan estándares de calidad en el proceso de desarrollo para
asegurar la satisfacción del usuario y el cumplimiento de los requerimientos.
Validación y calidad: Se utilizan pruebas automatizadas y herramientas informales para
garantizar la estabilidad y correcto funcionamiento del software.
Integración continua: Se implementa la integración continua para detectar errores de
manera temprana y mejorar la estabilidad del sistema.
Este enfoque optimiza los tiempos de desarrollo y permite que el software sea seguro y
estable desde sus primeras versiones.
1.3 Elementos a considerar en el desarrollo de los productos de software
Un banco busca desarrollar una aplicación móvil que facilite la gestión de cuentas
bancarias, transferencias y pagos en línea. Para lograrlo, el equipo de desarrollo adopta la
metodología Scrum, lo que permite un enfoque ágil y centrado en el usuario, garantizando
eficiencia en el proceso de desarrollo y adaptabilidad a los requerimientos cambiantes del
mercado.
Proceso de Desarrollo
Metodología Ágil y Enfoque Interativo: Se emplea un desarrollo incremental con sprints de
dos semanas, lo que facilita la entrega continua de software funcional, la incorporación de
mejoras iterativas y una respuesta rápida a las necesidades de los usuarios.
Equipos Multidisciplinarios: El equipo está conformado por programadores, diseñadores
UX/UI y analistas de negocio, quienes colaboran estrechamente para garantizar que el
producto final sea intuitivo, accesible y funcional.
Validación y Calidad: Se implementan pruebas automatizadas y herramientas de
aseguramiento de calidad que permiten identificar y corregir errores en las primeras etapas
del desarrollo.
Integración Continua: Se adopta un enfoque de integración y entrega continua (CI/CD) para
garantizar la estabilidad del sistema, detectar errores tempranos y optimizar la calidad del
código.
Estándares de Calidad y Mejores Prácticas: Se aplican estándares como CMMI para
evaluar la madurez del desarrollo y la metodología ISO 9001:2000 para asegurar la
satisfacción del usuario y el cumplimiento de los requisitos normativos.
1.4 Atributos y elementos de calidad en el desarrollo de software
Un importante desarrollador de software ha decidido crear una aplicación móvil que permita
a los usuarios gestionar sus gastos personales, facilitando la planificación financiera y el
seguimiento de ingresos y egresos. Con el objetivo de garantizar la calidad y eficiencia en el
desarrollo del software, se implementará un enfoque que combine metodologías ágiles y un
riguroso sistema de aseguramiento de la calidad, tal como se define en la misión de la
calidad en el desarrollo de software.
Metodología Ágil y Enfoque Iterativo: El equipo de desarrollo opta por la metodología
Scrum, que permitirá un desarrollo incremental mediante sprints de dos semanas. Cada
sprint se enfocará en la entrega de funcionalidades específicas que respondan a las
necesidades cambiantes de los usuarios, como la creación de presupuestos, la
categorización de gastos y la generación de informes de rendimiento financiero. Esto
garantiza que el software evolucione de acuerdo con las expectativas del mercado,
permitiendo adaptaciones rápidas y eficientes.
Equipos Multidisciplinarios: Para asegurar una visión holística del proyecto, se forma un
equipo multidisciplinario que incluye programadores, diseñadores de experiencia de usuario
(UX/UI), analistas de negocio y expertos en finanzas. Esta diversidad de perfiles permite
una colaboración efectiva y un intercambio constante de ideas, garantizando que la
aplicación no solo sea funcional, sino también intuitiva y atractiva para los usuarios finales.
Validación y Aseguramiento de Calidad: Desde el inicio del desarrollo, se implementan
pruebas automatizadas y herramientas de aseguramiento de calidad para validar cada
nueva funcionalidad. Las pruebas se realizan en paralelo con el desarrollo, permitiendo
identificar y corregir errores en las etapas iniciales del proceso. Este enfoque no solo mejora
la estabilidad del software, sino que también optimiza la calidad del código, alineándose con
el compromiso de la misión de calidad establecida.
Integración Continua: El equipo adopta un sistema de integración continua (CI) que permite
integrar y probar el código de manera regular. Esto garantiza que cualquier error se detecte
tempranamente, lo que a su vez facilita la corrección rápida y la mejora continua del
sistema. Además, se implementa un proceso de entrega continua (CD) para asegurar que
las versiones de la aplicación se desplieguen de forma segura y estable, lo que mejora la
confianza del usuario en el producto.
Estándares de Calidad y Mejores Prácticas: La calidad del proceso de desarrollo se evalúa
mediante la aplicación del modelo CMMI, que permite identificar áreas de mejora y
establecer mejores prácticas en la gestión del proyecto. Asimismo, se adoptan estándares
de calidad como ISO 9001:2000, que aseguran el cumplimiento de los requisitos del usuario
y fomentan la satisfacción del cliente a lo largo de todo el ciclo de vida del desarrollo.
1.5 Áreas de estudio y de investigación de la ingeniería de software
Metodología Ágil y Enfoque Iterativo: El equipo de desarrollo adoptará un ciclo de trabajo
basado en sprints de dos semanas. Cada sprint comenzará con una reunión de
planificación, donde se definirán las funcionalidades que se desarrollarán, tales como la
creación de presupuestos, el seguimiento de gastos y la implementación de notificaciones
de pago. Al final de cada sprint, se llevará a cabo una demostración del software
desarrollado, permitiendo obtener retroalimentación directa de los usuarios y realizar ajustes
necesarios en las próximas iteraciones.
Equipos Multidisciplinarios: El equipo estará compuesto por desarrolladores de software,
diseñadores UX/UI, analistas de negocio y expertos en seguridad financiera. Esta diversidad
de perfiles facilitará una colaboración efectiva, garantizando que la aplicación sea no solo
funcional, sino también intuitiva y visualmente atractiva. Se realizarán sesiones regulares de
brainstorming para fomentar la innovación y la creatividad en la resolución de problemas.
Validación y Aseguramiento de Calidad: Desde las etapas iniciales del desarrollo, se
implementarán pruebas automatizadas que validarán cada nueva funcionalidad. Estas
pruebas incluirán pruebas unitarias y de integración, que se ejecutarán de manera continua
para asegurar que el software se mantenga estable a lo largo del ciclo de desarrollo.
También se utilizarán herramientas de gestión de calidad que permitirán el seguimiento de
errores y la documentación de soluciones.
Integración Continua: El equipo adoptará un enfoque de integración continua (CI) para
integrar el código de manera regular, lo que permitirá detectar y corregir errores en las
etapas más tempranas. A medida que el código se desarrolla, se generarán builds
automáticas que facilitarán pruebas rápidas y garantizarán que cada nueva funcionalidad se
integre sin problemas en la base de código existente.
Estándares de Calidad y Mejores Prácticas: Para evaluar y mejorar la calidad del desarrollo,
se implementará el modelo de madurez de capacidades (CMMI). Esto permitirá identificar
áreas de mejora en los procesos y establecer mejores prácticas que optimicen el proyecto.
Adicionalmente, se seguirán los estándares ISO 9001:2000 para asegurar que se cumplan
los requisitos del usuario y que se fomente la satisfacción del cliente a lo largo de todo el
ciclo de vida del desarrollo.
Atributos y Elementos de Calidad: La aplicación no solo se enfocará en ofrecer
funcionalidades robustas, sino también en proporcionar una excelente experiencia de
usuario (UX). Para ello, se realizarán pruebas de usabilidad que permitirán identificar áreas
de mejora en la interfaz y la interacción del usuario con la aplicación. Se implementarán
prácticas de diseño centrado en el usuario, asegurando que la navegación sea fluida y que
la información sea fácilmente accesible.
Consideraciones Finales: A lo largo del proyecto, se llevarán a cabo reuniones
retrospectivas al final de cada sprint, donde el equipo podrá reflexionar sobre lo que
funcionó bien y lo que se puede mejorar. Esta práctica fomentará una cultura de mejora
continua, lo cual es esencial para el éxito del desarrollo de software en entornos ágiles.
2.1 Definición del ciclo de vida
Fases del Ciclo de Vida del Software
1. Recopilación de Requisitos y Análisis
Se llevan a cabo una serie de reuniones con los stakeholders para comprender las
necesidades del usuario y definir las funcionalidades principales de la aplicación.
Se establecen los criterios de éxito del proyecto y los indicadores de desempeño.
Se identifican los requisitos funcionales (transferencias, consulta de saldo, pago de
servicios) y no funcionales (seguridad, rendimiento, compatibilidad con dispositivos
móviles).
2. Diseño y Arquitectura del Software
Se define la arquitectura del sistema utilizando un enfoque modular y escalable, asegurando
la seguridad de los datos mediante cifrado y autenticación de usuarios.
Se crean diagramas UML, flujos de navegación y prototipos de interfaz de usuario para
evaluar la usabilidad de la aplicación.
Se establece la integración con APIs bancarias y plataformas de pago.
3. Desarrollo e Implementación
Se divide el trabajo en sprints de dos semanas, permitiendo la entrega incremental de
funcionalidades.
El equipo multidisciplinario, conformado por programadores, diseñadores UX/UI y analistas
de negocio, colabora de manera iterativa para mejorar el software en cada sprint.
Se implementan pruebas automatizadas para validar cada nueva función antes de su
integración en la aplicación.
4. Validación y Pruebas de Software
Se aplican pruebas unitarias para verificar la correcta ejecución de cada módulo.
Se llevan a cabo pruebas de integración para asegurar la correcta comunicación entre
componentes del sistema.
Se implementan pruebas de seguridad para detectar posibles vulnerabilidades y proteger la
información del usuario.
5. Despliegue e Integración Continua (CI/CD)
Se utiliza un enfoque de integración continua (CI) para detectar errores tempranos y
garantizar la estabilidad del software.
Se implementa un proceso de entrega continua (CD), permitiendo el despliegue automático
de actualizaciones sin interrupciones para los usuarios.
Se realizan pruebas de rendimiento en servidores y dispositivos móviles para optimizar la
experiencia del usuario.
6. Mantenimiento y Mejora Continua
Se monitorea el rendimiento de la aplicación mediante herramientas de análisis y
retroalimentación del usuario.
Se corrigen errores y se lanzan actualizaciones periódicas para mejorar la funcionalidad y la
seguridad.
Se incorporan nuevas funcionalidades basadas en la evolución del mercado y las
necesidades de los clientes.
Estándares de Calidad y Mejores Prácticas
Para garantizar la calidad del producto final, se adoptan los siguientes estándares y
modelos de calidad:
CMMI (Capability Maturity Model Integration): Evalúa la madurez del proceso de desarrollo y
ayuda a optimizar la gestión del proyecto.
ISO [Link] Establece buenas prácticas en la gestión de calidad, asegurando que el
software cumpla con los requisitos del cliente.
Normas de seguridad bancaria: Se implementan protocolos de autenticación multifactor
(MFA) y cifrado de datos para garantizar la protección de la información financiera.
2.2 Ciclos de vida
Como parte de la continuación del proyecto iniciado por el banco para desarrollar una
aplicación móvil de gestión de cuentas, transferencias y pagos, el equipo de desarrollo
avanza aplicando cada fase del ciclo de vida del software de manera estructurada. Tras
definir los requerimientos iniciales en conjunto con los stakeholders, se diseña una
arquitectura modular que permite escalabilidad, seguridad e integración con sistemas
bancarios existentes. A través de sprints de dos semanas, se implementan de forma
incremental funcionalidades clave como autenticación segura, consulta de saldo,
programación de pagos y notificaciones de actividad.
Durante el desarrollo, se utilizan pruebas automatizadas en cada iteración, integradas
dentro de un sistema de integración continua (CI), lo cual permite detectar errores
tempranamente y asegurar la calidad del producto. Al finalizar cada sprint, se valida el
incremento funcional con el Product Owner, permitiendo ajustes ágiles según la
retroalimentación del usuario. Una vez desplegada la versión inicial de la aplicación, se
inicia la fase de mantenimiento y mejora continua, corrigiendo defectos menores,
optimizando la experiencia del usuario e incorporando nuevas funcionalidades como gestión
de presupuestos y categorización de gastos.
Todo el ciclo está respaldado por estándares de calidad como CMMI e ISO 9001:2000,
asegurando que el proceso de desarrollo cumpla con las mejores prácticas de ingeniería de
software y garantizando un producto final estable, seguro y centrado en el usuario.
2.2.1 Cascada pura
El banco decide desarrollar una versión alternativa de su aplicación móvil utilizando la
metodología de cascada pura, que se basa en un proceso lineal y secuencial. Primero, se
realiza una recopilación exhaustiva de requisitos con los stakeholders, definiendo todas las
funcionalidades desde el inicio: gestión de cuentas, transferencias, pagos, y aspectos no
funcionales como seguridad y rendimiento. Estos requisitos quedan documentados y no se
modifican durante el desarrollo.
Luego, en la fase de diseño, se establece toda la arquitectura del sistema, incluyendo
diagramas UML, diseño de base de datos y prototipos de interfaz. Con esto definido, se
pasa a la implementación, en la que se desarrolla el sistema completo sin entregas
parciales. Las pruebas se realizan al final, incluyendo pruebas unitarias, de integración y de
seguridad.
Una vez validado el sistema, se despliega en los entornos productivos del banco y se inicia
el mantenimiento, corrigiendo errores y aplicando actualizaciones menores.
Este modelo tiene como ventaja principal la claridad y control en proyectos con requisitos
estables, además de generar una documentación detallada. Sin embargo, presenta
inconvenientes importantes: su rigidez dificulta adaptarse a cambios, los errores se detectan
tarde y la ausencia de retroalimentación continua puede resultar en un producto final que no
cumpla con las expectativas del usuario.
2.2.2 Cascada modificada
Como parte del enfoque alternativo al desarrollo de la aplicación móvil para el banco, el
equipo de ingeniería opta por implementar el modelo de cascada modificada. Este modelo
conserva la estructura secuencial del ciclo de vida tradicional (requisitos, diseño,
implementación, pruebas y mantenimiento), pero introduce una diferencia clave: permite
retrocesos controlados entre fases. Es decir, si durante la etapa de pruebas se detecta un
error en el diseño o una omisión en los requisitos, es posible volver a esa fase para realizar
los ajustes necesarios antes de continuar.
En este proyecto, tras una recopilación exhaustiva de requisitos con los stakeholders se
pasa a una etapa de diseño técnico y funcional detallado, donde se elabora la arquitectura
del sistema y los prototipos de interfaz de usuario. A diferencia de la cascada pura, esta
fase queda sujeta a revisión si en el desarrollo o pruebas aparecen inconsistencias.
Durante la implementación, se desarrolla el sistema en su totalidad, siguiendo lo establecido
en el diseño. Sin embargo, si durante las pruebas funcionales o de seguridad se detectan
desviaciones respecto a lo esperado, se puede volver al diseño o incluso a los requisitos
para corregirlos. Esto permite entregar un producto más alineado con las necesidades
reales del banco, sin abandonar el rigor documental y metodológico del enfoque clásico.
El sistema se despliega en los entornos operativos y entra en una fase de mantenimiento,
donde se aplican correcciones menores, se monitorean los servicios y se recopila
retroalimentación de usuarios para futuras versiones. La cascada modificada, en este caso,
actúa como un puente entre la rigidez del modelo tradicional y la adaptabilidad limitada,
pero suficiente, que necesita un sistema bancario donde los requisitos son claros, pero
pueden cambiar levemente con el tiempo.
2.2.3 Códificar y corregir
Durante las primeras etapas del desarrollo del sistema bancario móvil, el equipo decidió
explorar el modelo Codificar y Corregir como un enfoque experimental para avanzar
rápidamente en la construcción del prototipo. La intención era evaluar qué tan rápido podían
implementarse las funcionalidades esenciales y entregar un producto básico funcional para
revisión inicial por parte de los stakeholders.
A diferencia de los modelos tradicionales o ágiles previamente analizados, el enfoque
Codificar y Corregir elimina fases explícitas de planificación, análisis de requisitos o diseño
arquitectónico. En este caso, el equipo inició el desarrollo de la aplicación bancaria
directamente con la codificación de las funcionalidades centrales como la autenticación de
usuarios, la visualización de saldos, las transferencias bancarias y los pagos de servicios.
No se elaboró ningún documento técnico previo ni un diseño estructurado de la arquitectura
del sistema. Las decisiones técnicas se tomaban sobre la marcha, basadas en la intuición
del desarrollador y en las demandas inmediatas del cliente.
Tras la primera entrega funcional de la aplicación, surgieron errores graves relacionados
con la gestión de sesiones, problemas de concurrencia al realizar transferencias
simultáneas y validaciones de seguridad inconsistentes. En lugar de documentar los
problemas o rediseñar los módulos afectados, el equipo optó por realizar correcciones
directas en el código, sin pruebas exhaustivas ni procesos de revisión.
Por ejemplo, cuando un usuario reportó que podía realizar una transferencia sin saldo
suficiente, el programador encargado añadió una validación condicional simple directamente
en el método de transferencia, sin verificar cómo esta modificación afectaba otras
funcionalidades como el historial de transacciones o las notificaciones en tiempo real.
A medida que se fueron incorporando más funcionalidades el sistema comenzó a volverse
difícil de mantener y propenso a errores colaterales. La ausencia de una arquitectura
modular y de pruebas automatizadas impidió detectar inconsistencias hasta que los
usuarios finales las reportaron.
La falta de control de versiones, documentación técnica y gestión de cambios resultó en una
alta dependencia del conocimiento individual de cada desarrollador. Esto generó retrasos
importantes cuando uno de los miembros clave del equipo se ausentó, ya que no había
registro formal de las decisiones técnicas tomadas.
El modelo Codificar y Corregir permitió al equipo generar rápidamente una primera versión
funcional, lo cual resultó útil para validar visualmente ciertos aspectos de la interfaz y el flujo
general de la aplicación. Sin embargo, su uso en un entorno con altos requerimientos de
seguridad, estabilidad y trazabilidad como el bancario, demostró ser inadecuado.
En ausencia de pruebas rigurosas y documentación sólida, los errores se acumulaban y las
correcciones introducían nuevos fallos, afectando tanto la confianza del cliente como la
sostenibilidad del desarrollo. Como resultado, el equipo decidió abandonar este enfoque
tras la segunda iteración y migrar hacia un modelo más estructurado que permitiera
garantizar la calidad del producto a largo plazo.
2.2.4 Espiral
Ante la complejidad y los altos requisitos de seguridad del sistema bancario móvil, el equipo
opta por el modelo en espiral, ideal para proyectos con riesgos elevados y requisitos en
evolución. Este modelo combina el enfoque iterativo con una gestión estructurada de
riesgos en cada ciclo de desarrollo.
En la primera iteración se identifican riesgos críticos, como la seguridad en transacciones y
la compatibilidad multiplataforma, y se construye un prototipo inicial que permite validar
aspectos como autenticación y experiencia de usuario. En ciclos sucesivos, el prototipo se
amplía gradualmente, incorporando funcionalidades como pagos automatizados y alertas
antifraude, siempre con una evaluación continua de riesgos.
El modelo permite retroceder de forma controlada cuando se detectan problemas
significativos. Por ejemplo, tras detectar vulnerabilidades en la verificación en dos pasos, se
rediseñó esa parte del sistema. A diferencia de modelos más rígidos, la espiral permite
integrar la retroalimentación de usuarios y stakeholders en cada vuelta, lo que mejora la
calidad y pertinencia del producto final.
El proceso se apoya en normas como CMMI e ISO 9001:2000, garantizando calidad y
cumplimiento normativo. Gracias a este enfoque, el banco logra desarrollar una aplicación
segura, adaptable y orientada al usuario.
2.2.5 Prototipo evolutivo
El modelo de prototipo evolutivo se inicia con un análisis preliminar en el que se identifican
requerimientos esenciales como el inicio de sesión, la consulta de saldo, la transferencia
entre cuentas y el historial de movimientos con esta información se diseña un primer
prototipo funcional centrado en estas funcionalidades básicas y se presenta a los usuarios
para obtener retroalimentación inmediata a partir de sus comentarios se realiza una
iteración en la que se incorporan mejoras en la interfaz de usuario y se añaden nuevas
funcionalidades como la gestión de tarjetas, notificaciones en tiempo real y acceso mediante
huella digital cada ciclo de desarrollo consiste en modificar el prototipo existente, evaluarlo y
refinarlo de forma continua permitiendo que el sistema evolucione de manera orgánica hacia
una versión final que satisfaga de forma progresiva las necesidades del usuario este modelo
es especialmente adecuado para esta aplicación ya que permite adaptarse a cambios
frecuentes en requisitos, incorporar nuevas funciones bancarias según tendencias del
mercado y mejorar la experiencia del usuario a partir de pruebas reales entre las ventajas
del modelo se encuentran su flexibilidad, la detección temprana de errores, y una mejor
alineación con las expectativas del usuario mientras que como desventajas destacan la
dificultad para establecer plazos cerrados, posibles problemas de documentación y riesgos
de una expansión indefinida del alcance en este caso se emplea un modelo evolutivo
incremental centrado en versiones funcionales sucesivas del prototipo, lo que garantiza un
crecimiento controlado y un desarrollo orientado a la retroalimentación real del usuario
2.2.6 Entrega por etapas
En la definición del problema, se busca desarrollar una aplicación que permita a los
usuarios gestionar sus finanzas, realizando transacciones, consultando saldos y recibiendo
alertas. En esta fase, se asegura que los objetivos sean claros, aunque puede haber
dificultades si los requerimientos no están bien definidos desde el inicio.
En la fase de análisis de requerimientos, se documentan las funcionalidades como registro
de usuarios, consulta de saldo, transferencias, y notificaciones, así como aspectos de
seguridad y rendimiento. Esta fase ayuda a establecer una base sólida, pero puede ser
compleja y larga si las expectativas de los usuarios no se gestionan adecuadamente.
En el diseño global, se define la arquitectura técnica de la aplicación, eligiendo las
tecnologías necesarias para la base de datos, la plataforma móvil y la seguridad. Esto
permite una buena planificación, aunque cambiar la arquitectura puede ser costoso.
El diseño detallado profundiza en la estructura de la base de datos y la interfaz de usuario.
Aquí se detallan las interacciones y flujos de la aplicación, lo que facilita la implementación,
pero requiere mucho tiempo y esfuerzo.
En la etapa de codificación, los desarrolladores implementan las funcionalidades definidas,
creando la interfaz, la lógica y las integraciones necesarias. Si no se estructura bien el
código desde el principio, pueden surgir errores.
La fase de depuración se encarga de corregir errores y asegurar el correcto funcionamiento
de la aplicación, pero puede ser costosa y generar retrasos si el código no es de calidad.
En las pruebas, se verifica que la aplicación cumpla con todos los requerimientos
funcionales y no funcionales, garantizando la calidad del producto. Sin embargo, esta fase
puede ser extensa, especialmente si se hacen pruebas exhaustivas.
En la entrega, la aplicación se pone a disposición de los usuarios. En un enfoque de entrega
por etapas, se pueden lanzar funcionalidades gradualmente, lo que permite obtener
retroalimentación temprana y ajustar el producto. Sin embargo, esto puede generar
insatisfacción si no se entregan todas las características inicialmente.
2.2.7 Diseño por planeación
En el desarrollo de la aplicación móvil de cuenta bancaria se aplica el diseño por
planificación para asegurar una ejecución ordenada y eficiente del proyecto comenzando
con la fase de inicio se elabora un plan que define los objetivos como la creación de una
app segura y funcional establece los recursos requeridos los riesgos y un cronograma de
trabajo luego en la fase de requisitos de usuario se identifican funciones como consultas de
saldo transferencias alertas y autenticación segura validando estos requerimientos con el
cliente para evitar desviaciones durante el análisis se documentan todos los requisitos del
sistema incluyendo aspectos técnicos y normativos que guiarán la implementación durante
la construcción se desarrolla la aplicación utilizando tecnologías móviles actuales realizando
pruebas continuas para garantizar funcionalidad y seguridad una vez validado el sistema se
pasa a la implantación en donde se publica la app y se brinda soporte técnico corrigiendo
errores no detectados previamente y aplicando actualizaciones el proyecto se acompaña de
documentación interna como configuración de versiones copias de seguridad y control de
cambios lo que permite una trazabilidad completa y asegura la calidad del producto final
2.2.8 Entrega evolutiva
Para desarrollar una aplicación móvil de cuenta bancaria el enfoque de entrega evolutiva
resulta adecuado ya que permite lanzar una versión inicial con funciones básicas como
inicio de sesión seguro consulta de saldo e historial de movimientos luego de la entrega se
valida con los usuarios y se recogen comentarios lo que da paso a nuevas iteraciones
donde se integran funcionalidades como transferencias entre cuentas y generación de
comprobantes PDF durante este proceso las fases de especificación desarrollo y validación
no se separan sino que se entrelazan permitiendo una mejora continua además se utilizan
prototipos desechables para experimentar con funciones como autenticación biométrica sin
afectar el sistema principal aunque el proceso no es completamente visible desde la gestión
se compensa con entregas frecuentes y pruebas continuas para mantener la calidad técnica
con cada nuevo cambio y aunque el enfoque evolutivo puede poner en riesgo la estructura
interna del software se aplican refactorizaciones y controles para mantener la estabilidad en
conclusión este modelo facilita la adaptación a los requerimientos reales del cliente
mejorando gradualmente la aplicación bancaria según sus necesidades y expectativas
2.2.9 Diseño por herramientas
En el desarrollo de la aplicación móvil de cuenta bancaria se aplicó el diseño por
herramientas cubriendo cada etapa del ciclo de vida del software. En la planificación se
usaron plataformas como Trello para organizar tareas y establecer cronogramas. Durante el
análisis se identificaron requerimientos con ayuda de herramientas como Jama Connect y
entrevistas a usuarios del banco. En la fase de diseño se utilizaron herramientas de
modelado UML como MagicDraw para crear diagramas de casos de uso y clases que
representan el comportamiento de funciones clave como transferencias y consultas de
saldo. Para la implementación se usaron IDE como Android Studio y Visual Studio Code
además de GitHub para la colaboración del equipo. En la etapa de uso se incorporaron
herramientas de monitoreo como Firebase Analytics para analizar el comportamiento de los
usuarios y resolver errores.
Se eligió un prototipo de características seleccionadas iniciando con una versión funcional
centrada en login, consulta de saldo y transferencias básicas que fue evaluada por usuarios
internos permitiendo ajustes rápidos antes de incorporar nuevas funciones como historial de
movimientos y bloqueo de cuentas. Este enfoque permitió un desarrollo ágil con constante
retroalimentación manteniendo la calidad y adecuación del sistema a las necesidades reales
de los usuarios.
2.2.10 Herramientas de apoyo al desarrollo de sistemas
Durante el desarrollo de la aplicación móvil de cuenta bancaria, se utilizaron diversas
herramientas para asegurar un flujo de trabajo eficiente y colaborativo. Git se empleó para
el control de versiones y GitHub como plataforma central para almacenar el código, revisar
cambios y gestionar incidencias. El equipo programó principalmente en Java utilizando
IntelliJ IDEA como entorno de desarrollo por su capacidad de depuración y análisis. Jenkins
automatizó la integración continua, ejecutando pruebas después de cada modificación en el
repositorio, y Docker permitió ejecutar la aplicación en entornos controlados y portables.
Jira fue utilizada para planificar y gestionar historias de usuario dentro del marco Scrum,
mientras que Slack permitió una comunicación fluida entre los miembros del equipo.
Confluence centralizó la documentación técnica del proyecto. Stack Overflow y The Code
Project fueron recursos clave para resolver dudas durante el desarrollo, mientras que
Chrome DevTools ayudó a depurar y optimizar la interfaz de usuario. Para facilitar el trabajo
visual y la organización inicial de tareas, también se utilizó Trello. Todas estas herramientas
en conjunto permitieron mantener control, calidad y productividad en la construcción de la
aplicación.
2.3 Administración de proyectos en la ingeniería de software
La administración de proyectos en ingeniería de software implica planificar, organizar y
supervisar recursos técnicos y humanos para cumplir objetivos específicos de funcionalidad,
calidad, tiempo y costo. En el desarrollo de una aplicación móvil para gestionar cuentas
bancarias, esto se traduce en coordinar actividades que aseguren un producto seguro,
funcional y fácil de usar. Desde el inicio, se adopta un enfoque iterativo basado en
prototipos evolutivos, lo que permite validar funcionalidades clave como consulta de saldos
o transferencias con el usuario en cada fase. El equipo se estructura con roles definidos
para garantizar el cumplimiento de tareas técnicas y de gestión, y el líder del proyecto
supervisa el avance, distribuye responsabilidades y actúa como enlace con la entidad
bancaria.
Las reuniones de trabajo se realizan semanalmente con objetivos claros, revisando avances
y estableciendo nuevas metas, promoviendo la participación activa del equipo. Para
mantener la continuidad, cada rol cuenta con un suplente y se incentiva la rotación de
funciones. Se identifican y mitigan riesgos como demoras en la integración con servicios
bancarios, cambios imprevistos en los requisitos o falta de retroalimentación por parte del
cliente. Se priorizan los riesgos según su impacto, siendo críticos aquellos relacionados con
el compromiso del cliente, la mala interpretación de requerimientos o la carencia de
habilidades clave.
El calendario inicial contempla doce semanas divididas en fases: recolección de requisitos,
desarrollo del prototipo, construcción del producto mínimo viable, integración con servicios
bancarios, pruebas finales y despliegue. Este cronograma incorpora márgenes de
flexibilidad para absorber posibles contratiempos sin afectar la entrega final.
2.3.1 Recursos humanos
Durante el desarrollo de la aplicación móvil para cuentas, transferencias y pagos, el equipo
de dirección del proyecto implementa un enfoque planificado para gestionar eficazmente los
recursos humanos. Desde el inicio, se define un plan que establece los roles principales
como desarrolladores móviles, diseñadores UX/UI, analistas de negocio y especialistas en
seguridad. El organigrama del equipo refleja una estructura ágil y colaborativa liderada por
el director del proyecto, acompañado por un Scrum Master y un Product Owner, lo que
facilita la coordinación de tareas en ciclos de trabajo de dos semanas.
Para conformar el equipo, se negocia con otras áreas del banco y con consultoras externas,
priorizando perfiles con experiencia en entornos financieros y tecnologías móviles. Ante la
escasez de ciertos talentos, se ajusta el cronograma de incorporación y se ofrecen
capacitaciones en metodologías ágiles, integración continua y pruebas automatizadas. Esto
permite una adaptación rápida a las herramientas y procesos del proyecto.
A lo largo del desarrollo, se fomenta la cohesión del equipo mediante sesiones de
retrospectiva, acompañamiento entre compañeros y reconocimiento a los logros obtenidos.
La comunicación constante y la colaboración interdisciplinaria refuerzan el ambiente de
trabajo y optimizan la productividad. Los avances y dificultades se revisan semanalmente,
permitiendo ajustes ágiles en la asignación de tareas o en la solución de conflictos internos.
El liderazgo del proyecto impulsa una cultura de mejora continua y compromiso ético, clave
para lograr un equipo estable, motivado y alineado con los objetivos del banco.
.2.3.2 Productos
En el desarrollo de la aplicación móvil bancaria, el producto de software no se limita al
programa instalado en los dispositivos, sino que comprende también la documentación
técnica, los procedimientos de uso, las configuraciones de seguridad y los datos que
conforman el sistema. Conforme a la definición del IEEE, un producto de software es el
conjunto de programas, reglas y datos diseñados para un usuario, por lo que su desarrollo
exige un enfoque sistemático como el que promueve la ingeniería de software. Este enfoque
busca responder a problemas habituales como los retrasos en la planificación, la baja
productividad, las elevadas cargas de mantenimiento y la falta de alineación entre lo que se
necesita y lo que se construye.
En este proyecto, la integración de prácticas como el modelado ágil de requisitos, la
validación continua con usuarios reales y el uso de pruebas automatizadas permite construir
un producto fiable, adaptable y alineado con las expectativas del banco. Además del código
funcional, el producto incluye documentación, herramientas de despliegue y controles de
seguridad que aseguran la mantenibilidad del sistema. La adopción de modelos como CMMI
e ISO 9001:2000 refuerza la calidad y trazabilidad del software, permitiendo que el producto
evolucione con rapidez y confianza frente a nuevas demandas normativas o de negocio.
Así, el resultado es una solución robusta y centrada en el usuario, capaz de mantenerse
vigente en un entorno cambiante.
2.3.3 Procesos
En el desarrollo de la aplicación móvil bancaria, el equipo de proyecto adopta un enfoque
estructurado para la gestión de procesos, con el fin de enfrentar los retos asociados a la
eficiencia, la calidad y la sostenibilidad del software. Frente a la presión por cumplir con
plazos ajustados y mantener altos estándares de seguridad y usabilidad, se implementan
procesos que permiten planificar, ejecutar y controlar cada fase del desarrollo con precisión.
La adopción de modelos como CMMI asegura la madurez progresiva de las prácticas
organizacionales, permitiendo estandarizar procedimientos, reducir errores y aumentar la
trazabilidad.
De forma complementaria, se utiliza RUP como metodología base, lo cual proporciona un
marco iterativo y controlado para refinar requisitos, validar avances y responder a cambios
surgidos durante los sprints. Asimismo, se integran buenas prácticas derivadas de ISO 9001
para asegurar que el producto cumpla con los requisitos de calidad y documentación
esperados por el banco y las entidades regulatorias. A nivel individual, los desarrolladores
aplican elementos del PSP para mejorar sus estimaciones y planificación, mientras que el
equipo técnico opera bajo principios del TSP, coordinando entregas, seguimiento de tareas
y revisión entre pares. Este conjunto de procesos permite construir un producto robusto,
alineado con las expectativas del negocio, y con capacidad de evolucionar frente a nuevas
demandas funcionales o regulatorias.
3.1 Conceptualización de metodología de desarrollo de sistemas
En el desarrollo de la aplicación móvil bancaria, se reconoce que más allá del código
funcional y la interfaz, el éxito del proyecto depende en gran parte de la aplicación de una
metodología estructurada de desarrollo. En este caso, se adopta un enfoque basado en
metodologías ágiles, que permiten al equipo adaptarse a los cambios frecuentes del entorno
financiero y responder con rapidez a las necesidades emergentes de los usuarios. La
metodología empleada define con claridad las actividades a realizar en cada sprint,
promueve la revisión constante mediante retrospectivas, y garantiza la participación activa
de los usuarios mediante validaciones iterativas.
Este enfoque también unifica criterios dentro del equipo, mejora el rendimiento individual y
colectivo, y permite cumplir con los plazos definidos en la planificación inicial del proyecto.
La documentación técnica, aunque ligera, se genera de forma continua para mantener
trazabilidad y facilitar el mantenimiento posterior. El uso de esta metodología no solo mejora
la calidad del producto, sino también la eficiencia del equipo, generando una solución
confiable, usable y alineada con las expectativas de los clientes del banco.
3.2 Definición entre ciclo de vida y metodología de desarrollo de sistemas
En el caso de la aplicación móvil bancaria, el desarrollo del sistema se estructuró siguiendo
un modelo de ciclo de vida iterativo, lo que permitió planificar y revisar de forma progresiva
cada una de sus fases, desde la recolección de requisitos hasta el mantenimiento. Sin
embargo, este ciclo de vida no fue aplicado de forma aislada, sino bajo una metodología ágil
que definió claramente cómo debía organizarse el trabajo dentro de cada iteración. Mientras
el ciclo de vida indicaba qué debía lograrse en cada fase, como un prototipo funcional o la
validación de una funcionalidad crítica, la metodología proporcionaba las herramientas,
roles y buenas prácticas necesarias para lograrlo de forma efectiva y colaborativa.
Gracias a esta combinación, el equipo logró mantener el enfoque en la calidad y la
satisfacción del usuario, adaptándose rápidamente a los cambios regulatorios y a las
nuevas demandas del entorno financiero. La metodología ágil, al estar alineada con el ciclo
de vida seleccionado, permitió mejorar la planificación, facilitar la revisión constante de
avances, y mantener al equipo alineado con los objetivos del producto. Esta integración
efectiva entre ciclo de vida y metodología aseguró una entrega incremental exitosa,
centrada en el cliente y con alto grado de fiabilidad técnica.
