Informe

FACULTAD DE INGENIERÍA ARQUITECTURA Y
URBANISMO
ESCUELA PROFESIONAL DE INGENIERÍA DE

SISTEMAS
CURSO:
REQUERIMIENTOS DE SOFTWARE
PROYECTO:
IDEA DE NEGOCIO - TRUEQ
ALUMNOS:
RIMRACHIN ESCRIBANO, RUT
VALLEJOS RAMOS, FERNANDO
PISFIL SUGARAY, ESTUARDO
CALDERON PIZANGO, FLAVIO
DOCENTE:
ING. VÍCTOR TUESTA MONTEZA

I. RESUMEN
Arquitectura empresarial, un termino que sigue dándose a conocer en el
mercado de las enormes estrategias de negocio. Las grandes organizaciones
que aplican arquitectura empresarial reflejan mejoras y beneficios en sus
procesos de negocio cuando alinean la tecnología a sus objetivos estratégicos.
Cuando no integran las aplicaciones, información, procesos y tecnología a los
objetivos estratégicos, suele desperdiciar muchos recursos y afectar más a su
competitividad. Por esto es necesaria la integración a través de un framework
togaf de arquitectura empresarial que permita a la empresa asumir de la mejor
forma posible los continuos cambios.
En este proyecto se describe la investigación aplicada a una idea de negocio
de cambio de divisas, donde se diseñó arquitectura empresarial aplicable al
0sector financiero.
El objetivo general de este proyecto consistió en el diseño de arquitectura
empresarial aplicable a la idea de negocio Trueq con el fin de que se considere
la importancia de la implementación de arquitectura empresarial en
instituciones financieras.
Palabras claves:
Arquitectura Empresarial, Arquitectura de negocio, arquitectura tecnológica,
requerimientos.
II. INTRODUCCIÓN
Las aplicaciones móviles en la actualidad son muy utilizadas gracias a las
facilidades de acceso a internet existentes, así como los avances tecnológicos
de teléfonos inteligentes, estos cuentan con sistemas operativos que facilitan
desarrollar aplicaciones gratuitas que se pueden instalar en un dispositivo
móvil sin ningún problema. Al realizar un análisis de los beneficios que ofrece
la tecnología se propuso una aplicación móvil para la publicación,
autentificación y marketing digital, de proyectos, ya sean de investigación o
una simple propuesta de negocio, dando la facilidad a los usuarios de
interactuar desde el sitio que se encuentre.
Existen ideas de nuevos profesionales o de personas emprendedoras, que no
se han realizado, muchas por falta de dinero o de estrategias que permitan el
surgimiento de la misma. También existen inversionistas que cuentan dinero
que no les está generando intereses, que buscan propuestas, ideas, proyectos
donde invertir.
Ante la situación y aprovechando los grandes beneficios que brinda el uso de
tecnologías, esta startup a realizar se enfoca en ayudar a emprendedores a
publicar sus ideas y a inversionistas interactuar con los autores de la idea de
su interés e invertir, evitando entrevistas que demandan tiempo, además estas
ideas cargadas a la aplicación tienen acceso al marketing digital que sea de su
preferencia el cuál será presentado en distintos paquetes de adquisición, como
factor monetario de la startup.

El desarrollo de este informe se basa en los estándares de la ingeniería de
requerimientos y los procesos que incluye la misma. Ha sido elaborado por
estudiantes de Ingeniería de Sistemas de la Universidad Señor de Sipán.
III. OBJETIVOS
Objetivo general
Realizar un análisis de requerimientos para diseñar el sistema Trueq’.
Objetivos específicos
o Construir el marco teórico.
o Modelar el negocio.
o Modelar la arquitectura de negocio.
o Modelar la arquitectura de datos.
o Modelar la arquitectura de aplicaciones.
o Desarrollar los prototipos de la Aplicación.
o Desarrollar Modelos de Secuencia.
o Desarrollar la base de datos.
o Validar los Requerimientos.

IV. MARCO TEORICO
4.1. Modelos de negocio
Un modelo de negocio es una herramienta previa al plan de negocio que
te permitirá definir con claridad qué vas a ofrecer al mercado, cómo lo vas
a hacer, a quién se lo vas a vender, cómo se lo vas a vender y de qué forma
vas a generar ingresos. Es una herramienta de análisis que te permitirá
saber quién eres, cómo lo haces, a qué coste, con qué medios y qué fuentes
de ingresos vas a tener. (Emprendedores, 2019)
4.2.Arquitectura Empresarial
La arquitectura empresarial en una organización corresponde a la forma de
representar de manera integral la empresa, permitiendo cubrir y considerar
todos y cada uno de los elementos que la conforman. Esto conduce a que
se pueda establecer una visión clara sobre los objetivos, las metas y líneas
de negocio en la empresa, comenzando desde la perspectiva estratégica
(misión, visión, lineamientos e indicadores estratégicos), hasta llegar a una
estructura actual y futura para los procesos de la organización; la cual
incorpora algunos de los componentes que se consideran como críticos
para su funcionamiento:
o Los procesos: modelos de negocio y procesos.
o La estructura organizacional: personas, estructuras
administrativas.
o Las tecnologías de información: aplicaciones, información,
infraestructura tecnológica y seguridad informática.
(EvaluandoSoftware, 2016)
4.3.Frameworks TOGAF
Es un framework que proporciona un enfoque para diseñar, planificar,
implementar y gobernar una arquitectura de tecnología de la información
empresarial. Presenta una metodología para el desarrollo de artefactos de
arquitectura o documentos. Enfatiza en las metas del negocio como
directrices de la arquitectura y provee un repositorio de “buenas
prácticas”, es un guía para definir las directrices a partir de las cuatro
arquitecturas que la componen. El Método de Desarrollo de Arquitectura
TOGAF (ADM) describe el proceso para desarrollar la Arquitectura
Empresarial específica para una organización a partir de los
requerimientos del negocio (Castaño & Varon G, 2017)
Beneficios comerciales
TOGAF ayuda a las organizaciones a implementar la tecnología de
software de una manera estructurada y organizada, con un enfoque en la
gobernanza y el cumplimiento de los objetivos comerciales. Los enlaces
de desarrollo de software entre múltiples departamentos y unidades de
negocio, tanto dentro como fuera de TI, TOGAF ayuda a resolver todos
los problemas relacionados con la obtención de las partes interesadas clave
en la misma página. (Sara, 2018)
TOGAF está destinado a ayudar a crear un enfoque sistemático para
agilizar el desarrollo para que pueda ser replicado, con el menor número
posible de errores a medida que cada fase del desarrollo cambia de manos.
Al crear un lenguaje común que acople las brechas entre las TI y las
empresas, ayuda a brindar claridad a todos los involucrados. Es un
documento extenso, pero no tiene que adoptar todas las partes de TOGAF.
Las empresas están mejor que sus necesidades para determinar en qué
partes del marco enfocarse. (Sara, 2018)
4.3.1. ADM
El ADM es el resultado de las contribuciones de numerosos
profesionales de la arquitectura y constituye el núcleo de
TOGAF. Es un método para obtener arquitecturas
empresariales que son específicas para la organización, y está
especialmente diseñado 23 para responder a los requerimientos
del negocio. El ADM describe un modo confiable y probado
para desarrollar y utilizar una arquitectura empresarial, un
método para desarrollar arquitecturas en diferentes niveles
(negocio, aplicaciones, datos, tecnología) que permiten al
arquitecto asegurar que un conjunto complejo de
requerimientos se aborde adecuadamente, un conjunto de guías
y técnicas para el desarrollo de la arquitectura. (Josey,
Harrison, Rouse, & Van Sante, 2013)
El ADM provee un conjunto de guías y técnicas para el
desarrollo de una arquitectura empresarial. Está compuesto por
9 fases las cuales cubren los cuatro dominios de la arquitectura
empresarial (Negocios, Datos, Aplicación y Tecnológica) y se
aplica iterativamente entre las fases y dentro de ellas, lo que

permite asegurar que los requerimientos se aborden
adecuadamente. (Casusol & Ramirez, 2017)
4.4.Ingeniería de Software
La Ingeniería de Software es la rama de la ingeniería que estudia todo lo
relacionado con la informática o sistemas de computación, con una
orientación metódica, ordenada y cuantificable al incremento, ejecución y
conservación del software. (MiCarreraUniversitaria, 2018)
4.4.1. Ciclo de vida de Software
El término ciclo de vida del software describe el desarrollo de
software, desde la fase inicial hasta la fase final. El propósito
de este programa es definir las distintas fases intermedias que
se requieren para validar el desarrollo de la aplicación, es decir,
para garantizar que el software cumpla los requisitos para la
aplicación y verificación de los procedimientos de desarrollo:
se asegura de que los métodos utilizados son apropiados.
(Mary, 2017)
El ciclo de vida permite que los errores se detecten lo antes
posible y, por lo tanto, permite a los desarrolladores
concentrarse en la calidad de software, en los plazos de
implementación y en los costos asociados. (Mary, 2017)

Adopción e identificación del sistema
Es importante conocer el origen del sistema, así como las
motivaciones que impulsaron el desarrollo del sistema (por
qué, para qué, etc.) (Mary, 2017)
Análisis de requerimientos
Identificación de las necesidades del cliente y los usuarios que
el sistema debe satisfacer. (Mary, 2017)
Especificación
Los requerimientos se realizan en un lenguaje más formal, de
manera que se pueda encontrar la función de correspondencia
entre las entradas del sistema y las salidas que se supone que
genera. Al estar completamente especificado el sistema, se
puede hacer estimaciones cuantitativas del coste, tiempo de
diseño y asignación de personal al sistema, así como la
planificación general del proyecto. (Mary, 2017)

Especificación de la arquitectura
Define las interfaces de interconexión y recursos entre
módulos del sistema de manera apropiada para su diseño
detallado y administración. (Mary, 2017)
Diseño
En esta etapa, se divide el sistema en partes manejables que,
como anteriormente hemos dicho se llaman módulos, y se
analizan los elementos que las constituyen. Esto permite
afrontar proyectos de muy alta complejidad. (Mary, 2017)
Desarrollo e implementación
Codificación y depuración de la etapa de diseño en
implementaciones de condigo fuente operacional. (Mary,
2017)
Integración y prueba del software
Ensamble de los componentes de acuerdo a la arquitectura
establecida y evaluación del comportamiento de todo el
sistema atendiendo a su funcionalidad y eficacia. (Mary, 2017)
Documentación
Generación de documentos necesarios para el uso y
mantenimiento (Mary, 2017)

Entrenamiento y uso
Instrucciones y guías para los usuarios detallando las
posibilidades y limitaciones del sistema, para su uso efectivo.
(Mary, 2017)
Mantenimiento del software
Actividades para el mantenimiento operativo del sistema. Se
clasifican en: evolución, conservación y mantenimientos
propiamente dicho. (Mary, 2017)
4.4.2. Metodologías de desarrollo de software
Una metodología de software es un enfoque, una manera de
interpretar la realidad o la disciplina en cuestión, que en este
caso particular correspondería a la Ingeniería de Software. De
hecho, la metodología destinada al desarrollo de software se
considera como una estructura utilizada para planificar y
controlar el procedimiento de creación de un sistema de
información especializada. (Karel, 2017)
Dicho esto, mostramos a continuación cuáles son algunas de
las metodologías de desarrollo que te permitirán saber cuál
sería la más adecuada para tu negocio. (Karel, 2017)
Modelo de cascada
El modelo de cascada es el modelo de paradigma más simple
en desarrollo de software. Sigue un modelo en que las fases del
SDLC funcionarán una detrás de la otra de forma lineal. Lo que
significa que solamente cuando la primera fase se termina se

puede empezar con la segunda, y así progresivamente.
(TutorialsPoint, 2019)
Este modelo asume que todo se lleva a cabo y tiene lugar tal y
como se había planeado en la fase anterior, y no es necesario
pensar en asuntos pasados que podrían surgir en la siguiente
fase. Este modelo no funcionará correctamente si se dejan
asuntos de lado en la fase previa. La naturaleza secuencial del
modelo no permite volver atrás y deshacer o volver a hacer
acciones. (TutorialsPoint, 2019)
Este modelo es recomendable cuando el desarrollador ya ha
diseñado y desarrollado softwares similares con anterioridad,
y por eso está al tanto de todos sus dominios. (TutorialsPoint,
2019)
Modelo repetitivo
Este modelo guía el proceso de desarrollo de software en
repeticiones. Proyecta el proceso de desarrollo de forma cíclica
repitiendo cada paso después de cada ciclo en el proceso de
SDLC. (TutorialsPoint, 2019)
El software primero se desarrolla en menor escala y se siguen
y tienen en consideración todos los pasos. Entonces, por cada
repetición, más módulos y características son diseñados,
codificados, evaluados y añadidos al software. Cada ciclo
produce un software completo, con más características y
capacidad que los previos. (TutorialsPoint, 2019)
Después de cada repetición, el equipo directivo puede
concentrarse en la gestión de riesgos y prepararse para la
siguiente repetición. Como el ciclo incluye pequeñas porciones
de la totalidad del proceso software, es más fácil gestionar el
proceso de desarrollo, pero a la vez se consumen más recursos.
Modelo en espiral
El modelo espiral en ingeniería del software tiene un enfoque
muy distinto al modelo de cascada, principalmente porque su
enfoque va dirigido hacia el análisis de riesgos. El modelo de
ciclo de vida en espiral, consiste en realizar diversas
iteraciones, pasando por cada una de sus fases una y otra vez.
A diferencia de la modelo cascada que no tiene vuelta atrás, en
el modelo en espiral se pueden hacer las iteraciones que se
consideren necesarias y estas son sus fases principales:
(OKHosting, 2018)
1. Determinación de Objetivos
2. Análisis de riesgos
3. Desarrollo y Pruebas
4. Planificación
Entre las principales ventajas de desarrollar un proyecto con el
modelo espiral, es que los riesgos se van disminuyendo
conforme avanzan los ciclos o iteraciones, de hecho no puedes
avanzar a un ciclo nuevo, si no se ha dado solución a todos los
riesgos latentes. Lamentablemente el modelo es realmente
costoso y para que puedas tener un alto nivel de eficacia en la
evaluación final de tu proyecto con este ciclo de vida, necesitas
que tu equipo tenga un gran nivel de conocimientos y si es

posible buena experiencia para superar cualquier riesgo al cual
se puedan enfrentar. (OKHosting, 2018)
Modelo V
El mayor inconveniente del modelo de cascada es que solo se
pasa a la siguiente fase cuando se completa la anterior, por
tanto, no es posible volver atrás si se encuentra algún error en
las etapas posteriores. El Modelo V aporta opciones de
evaluación del software en cada etapa de manera inversa.
En cada etapa, se crea la planificación de las pruebas y los
casos de pruebas para verificar y validar el producto según los
requisitos de la etapa. Por ejemplo, en la etapa de recogida de
requisitos, el equipo de evaluadores prepara las pruebas de caso
correspondientes a los requisitos. Más tarde, cuando el
producto se desarrolla y está preparado para ser evaluado, las
pruebas de caso en esta etapa verifican el software y su validez
según sus requisitos. (TutorialsPoint, 2019)

Esto hace que tanto la verificación como la validación vayan
en paralelo. Este modelo también se conoce como modelo de
validación y verificación. (TutorialsPoint, 2019)
Modelo Big Bang
Este modelo es el modelo con la forma más simple. Requiere
poca planificación, mucha programación y también muchos
fondos. Este modelo se conceptualiza alrededor de la teoría de
creación del universo 'Big Bang'. Tal como cuentan los
científicos, después del big bang muchas galaxias, planetas y
estrellas evolucionaron. De la misma manera, si reunimos
muchos fondos y programación, quizá podemos conseguir el
mejor producto de software. (TutorialsPoint, 2019)

Para este modelo, se requiere poca planificación. No sigue
ningún proceso concreto, y a veces el cliente no está seguro de
las futuras necesidades y requisitos. Por tanto, la entrada o
input respecto a los requisitos es arbitraria. (TutorialsPoint,
2019)
Este modelo no es recomendable para grandes proyectos de
software, pero es bueno para aprender y experimentar.
Modelo de prototipo
Es un procedimiento de desarrollo especializado que permite a
los desarrolladores la posibilidad de poder solo hacer la
muestra de la resolución para poder validar su esencia
funcional ante los clientes, y hacer los cambios que sean
fundamentales antes de crear la solución final auténtica. De
hecho, la mejor parte de esta metodología es que tiende a
resolver un conjunto de problemas de diversificación que
ocurren con el método de la cascada. (Karel, 2017)

Además de esto, la gran ventaja de optar por este enfoque es
que da una idea clara sobre el proceso funcional del software,
reduce el riesgo de falla en una funcionalidad de software y
asiste bien en la recolección de requisitos y en el análisis
general. (Karel, 2017)
Modelo de programación extrema (XP)
Como metodología ágil de ingeniería de software, la
metodología de programación extrema se conoce actualmente
como metodología de XP (eXtreme Programming). Esta
metodología, se utiliza principalmente para evitar el desarrollo
de funciones que actualmente no se necesitan, pero sobre todo
para atender proyectos complicados. Sin embargo, sus métodos
peculiares pueden tomar más tiempo, así como recursos
humanos en comparación con otros enfoques. (Karel, 2017)
Estas son solo algunas de las metodologías de Desarrollo de
Software que existen, pero lo importante es que tengas en

cuenta que al estar familiarizado con estos populares enfoques
podrás optimizar la eficiencia de tus proyectos utilizando un
enfoque puro o combinando algunos de ellos. (Karel, 2017)
Modelo Scrum
El ciclo de vida del sistema, puede agilarse si se utiliza la
metodología Scrum, uno de los modelos del ciclo de vida del
desarrollo del software más populares y más recientes, bueno
no tanto, pero si más que los de antaño. El modelo Scrum, se
encuentra basado en lo que es el desarrollo incremental, es
decir, conforme pasen las fases y las iteraciones, mayor va a
ser el tamaño del proyecto que se esté desarrollando, es por eso
que uno de los principales requisitos para llevarlo a cabo, es
que tu equipo de desarrollo sea de calidad. Teniendo una alta
calidad en el equipo, tendremos garantizado un excelente
funcionamiento. (OKHosting, 2018)
Como te mencionaba al principio, el modelo Scrum, deja de
seguir metodologías lineales, podemos despedirnos del modelo

cascada y secuencial, pues ahora procedemos a solapar las
fases y no importará en qué momento tengas que volver atrás,
siempre habrá un equipo de trabajo de buena calidad, que tenga
ese soporte para aguantar los cambios que son ciertamente
normales dentro de la metodología Scrum. Por último, como
ingrediente vital tenemos la comunicación, y es que acá
olvídate de las tendencias de ese jefe que te tienen envuelto en
una burbuja desarrollando. Con el modelo scrum podrás estar
comunicado con tu equipo de trabajo en todo momento, para
estar al tanto de los sucesos. (OKHosting, 2018)
Ahora veremos brevemente, cuáles son los procesos que el
modelo Scrum utiliza:
1. Product Backlog
2. Sprint Backlog
3. Sprint Planning Meeting
4. Daily Scrum o Stand-up Meeting
5. Sprint Review
6. Sprint Retrospective
Estas son las fases del ciclo de vida del software en esta
metodología, el cuál básicamente consiste en realizar un
análisis de los requerimientos del sistema (Product Backlog),
señalar cuáles serán los objetivos a corto o mediano plazo

dentro de un sprint, ósea, la fase de desarrollo. Posteriormente
los desarrolladores harán lo suyo, se realizan algunas pruebas
y se retroalimenta de acuerdo a lo conseguido al terminar la
última fase. Recuerda que aquí, se pueden añadir nuevas cosas
en todo momento, pues el modelo Scrum no se bloquea en
ninguna de sus fases. (OKHosting, 2018)
4.4.3. Frameworks de administración de proyectos de software
a) Scaled Agile Framework (SAFe): Según su creador Dean
Leffingwell, SAFe es una base de conocimientos libre para la
aplicación de patrones probados para desarrollar software
implementando Lean-Agile en proyectos a escala empresarial.
Su objetivo principal es proporcionarles a las organizaciones
una guía general para aumentar la productividad en el
desarrollo de software a todos los niveles de una organización.
En la versión más reciente de SAFe se proporcionan cuatro
niveles sobre los que se pueden aplicar prácticas Lean-Agile:
o Un nivel para los Equipos donde se proporciona un
modelo para equipos ágiles basados en Scrum y
prácticas XP.
o Un nivel de Programa donde los esfuerzos de múltiples
equipos ágiles se integran para ofrecer valor a la
empresa en un Agile Release Train.
o Un nivel de Portfolio, donde los programas se alinean
con las estrategias del negocio y su intención de
inversión.
o Y finalmente un nivel opcional para Flujo de Valor
donde se orquestan la entrega de valor de distintos
Agile Release Train.
b) Disciplined Agile Delivery (DAD):
Disciplined Agile Delivery (DAD) es un enfoque ágil híbrido
orientado al aprendizaje y orientado al aprendizaje para la
entrega de soluciones de TI. Tiene un ciclo de vida de entrega
de valor de riesgo, está orientado a objetivos, es consciente de
la empresa y es escalable. (Project Management Institute).
DAD es un framework híbrido creado por Scott Ambler y Mark
Lines en sus años en IBM. Al igual que SAFe se basa en
principios ágiles para combinar prácticas extraídas de Scrum,
XP, Kanban y Lean, pero añadiendo la particularidad de incluir
conceptos asociados a la disciplina de DevOps para la entrega
y despliegue continuo. El objetivo de DAD es ayudar a las
empresas a implantar valores y principios ágiles no solo para
etapas de desarrollo sino para soportar el ciclo completo desde

la definición de requisitos hasta el despliegue del software
construido (Mangialomini, 2017).
El ciclo se divide en tres fases:
o El Comienzo (Inception): Que es una fase corta de
preparación antes de comenzar a desarrollar. En ella se
definen requisitos, responsables y se planifican las
entregas. Esta fase parte de la base de construir
software con equipos multifuncionales y
autoorganizados.
o La Construcción (Construction): Esta es la fase de
desarrollo en sí. Al final de ella tendremos un producto
listo y que puede entregarse al cliente. En esta fase,
DAD da la libertad de utilizar Scrum o Lean como flujo
continuo de trabajo.
o La Transición (Transition): Es la fase de despliegue
de la solución donde se mencionan actividades
complementarias como la inclusión de demos y
formación para los usuarios.
c) Large Scale Scrum (LeSS):
Craig Larman y Bas Vodde proponen un framework de dos
dimensiones que permiten el escalado de Scrum en función del
tamaño de la empresa.
Scrum es un marco de desarrollo de procesos y controles
empírica en la que un auto-gestión de funciones cruzadas
equipo desarrolla un producto en forma incremental iterativo.
Cada Sprint en caja de tiempo, se entrega un incremento de
producto potencialmente enviable y, idealmente, se envía. Un
solo propietario del producto es responsable de maximizar el
valor del producto, priorizar los elementos en la cartera de
pedidos del producto y decidir de forma adaptativa el objetivo
de cada Sprint en función de los comentarios y el aprendizaje
constantes. Un pequeño equipo es responsable de cumplir la
meta de Sprint; no hay roles limitantes de especialización
única. Un maestro scrum enseña por qué Scrum y cómo derivar
valor con él, entrena al propietario del producto, el equipo y la
organización para aplicarlo, y actúa como un espejo. No hay
gerente de proyecto o líder de equipo. (The LeSS Company
B.V.).
El control empírico del proceso requiere transparencia, que
proviene del desarrollo de ciclo corto y la revisión de los
incrementos de productos que se pueden enviar. Enfatiza el
aprendizaje continuo, la inspección y la adaptación sobre el
producto y cómo se crea. Se basa en la comprensión de que en
el desarrollo las cosas son demasiado complejas y dinámicas
para recetas de proceso detalladas y formuladas, que inhiben el
cuestionamiento, el compromiso y la mejora.

d) Nexus:
El enfoque de Nexus propone que un grupo de equipos Scrum
trabaje en conjunto para integrar soluciones centralizadas de un
único Product Backlog.
Al igual que Scrum, es fácil comenzar con Nexus. Sin
embargo, las organizaciones que ya están familiarizadas con
Scrum podrán beneficiarse de sus conocimientos. Una de los
lineamientos principales de Nexus es que las organizaciones
promuevan la excelencia técnica como base para el
crecimiento. Para iniciarse con Nexus los principales puntos a
tener en cuenta son:
o Tener claramente identificados los equipos.
o Tener un sola Pila de Producto.
o Tener una Pila de Nexus para cada conjunto de equipos.
o Formar un Equipo de Integración Nexus por Pila.
o Identificar una definición de “Hecho”.
o Identificar una cadencia para los Sprints.
4.5.Ingeniería de requerimientos de software
Es el proceso de desarrollar una especificación de Software. Las especificaciones
pretenden comunicar las necesidades del sistema del cliente con los
desarrolladores del sistema. Trata de los principios, métodos, técnicas y
herramientas que permiten descubrir, documentar y mantener los requisitos para
sistemas basados en computadora, de forma sistemática y repetible.

Según Pressman (Pressman, 2010), es un conjunto de procesos, tareas y técnicas
que permiten la definición y gestión de los requisitos de un producto de un mod
sistemático. En definitiva, facilita los mecanismos adecuados para comprender
las necesidades del cliente, analizando sus necesidades, confirmando su
viabilidad, negociando una solución razonable, especificando la solución sin
ambigüedad, validando la especificación y gestionando los requisitos para que se
transformen en un sistema operacional.
Para Pressman, en el proceso de análisis de requerimientos del software se puede
identificar cinco tareas o etapas fundamentales:
a) Reconocimiento del problema.
Se deben de estudiar inicialmente las especificaciones del sistema y el
plan del proyecto del software. Realmente se necesita llegar a
comprender el software dentro del contexto del sistema. El analista debe
establecer un canal adecuado de comunicación con el equipo de trabajo
involucrado en el proyecto. En esta etapa la función primordial del
analista en todo momento es reconocer los elementos del problema tal y
como los percibe el usuario.
b) Evaluación y síntesis.
En esta etapa el analista debe centrarse en el flujo y estructura de la
información, definir las funciones del software, determinar los factores
que afectan el desarrollo de nuestro sistema, establecer las características
de la interfaz del sistema y descubrir las restricciones del diseño. Todas
las tareas anteriores conducen fácilmente a la determinación del
problema de forma sintetizada.
c) Modelización.
Durante la evaluación y síntesis de la solución, se crean modelos del
sistema que servirán al analista para comprender mejor el proceso

funcional, operativo y de contenido de la información. El modelo servirá
de pilar para el diseño del software y como base para la creación de una
especificación del software.
d) Especificación.
Las tareas asociadas con la especificación intentan proporcionar una
representación del software. Esto más adelante permitirá llegar a
determinar si se ha llegado a comprender el software, en los casos que se
lleguen a modelar se pueden dejar plasmados manuales.
e) Revisión.
Una vez que se han descrito la información básica, se especifican los
criterios de validación que han de servir para demostrar que se ha llegado
a un buen entendimiento de la forma de implementar con éxito el
software. La documentación del análisis de requerimientos y manuales,
permitirán una revisión por parte del cliente, la cual posiblemente traerá
consigo modificaciones en las funciones del sistema por lo que deberán
revisarse el plan de desarrollo y las estimaciones previstas inicialmente.
4.6.Técnicas y herramientas de elicitacion de requerimientos de software.
Según la guía de gestión de software Babok define ‘Elicitar’:
‘Elicitar’ requerimientos es una tarea clave en el Análisis de Negocio.
Debido a que los requerimientos sirven como fundamento para la solución
de necesidades de negocio, es esencial que los requerimientos estén
completos, y sean claros, correctos, y coherentes. Está plenamente
demostrado que la ‘‘elicitación’’ de requerimientos ayudará a alcanzar las
metas de calidad. (International Institute of Business Analysis., 2009).

Según la guia babok 2.0 identifica las siguientes tecnicas.
o Tormenta de ideas.
o Analisis de documentos.
o Grupos de opinion.
o Analisis de interfaces.
o Entrevistas.
o Observacion.
o Prototipos.
o Talleres de requerimientos.
o Encuestas y cuestionarios.
4.7.Técnicas y herramientas de adquisición de requerimientos de
software.
Mientras la ‘elicitación’ se desarrolla, se espera que en algún punto se haya
‘elicitado’ suficiente material de los expertos del negocio para permitir el
inicio de las actividades
de análisis. Los resultados combinados de todas las técnicas de
‘elicitación’ utilizadas serán usados como entrada para la construcción de
los modelos analíticos seleccionados. Los requerimientos faltantes,
incompletos o incorrectos, idealmente, se expondrán durante las
actividades del análisis, requiriendo así una ‘elicitación’ adicional.
a) Preparar la ‘elicitación’.
 Propósito.
Asegurar que todos los recursos necesarios estén organizados y
programados para la realización de las actividades de
‘elicitación’.
 Descripción.
Preparar un cronograma detallado para una actividad específica
de ‘elicitación’, definiendo las actividades específicas y las
fechas planificadas.
 Entradas.
Necesidad de negocio: Requerida para asegurar que el Analista
de Negocio entienda qué información debería ser ‘elicitada ’de
los stakeholders. Esta entrada se utiliza cuando se ‘elicitan’
requerimientos del negocio (con excepción de la necesidad de
negocio en sí misma).
Alcance de la solución y caso de negocio: Requeridos para
asegurar que el Analista de Negocio entienda qué información
debería ser ‘elicitada’ de los stakeholders. Estas entradas son
utilizadas cuando se ‘elicitan’ requerimientos de los
stakeholders, de solución y de transición.
Lista, roles y responsabilidades de los stakeholders: Usada
para identificar los stakeholders que deberían participar en las
actividades de ‘elicitación’.
 Elementos.
 Aclarar el alcance específico para la técnica de
‘elicitación’ seleccionada y reunir todo material
de apoyo necesario.
 Programar todos los recursos (personas,
instalaciones, equipo).
 Notificar el plan a las partes apropiadas.
Para la ‘elicitación’ basada en eventos (tormenta de ideas,
grupos de opinión, entrevistas, observación, prototipos, talleres
de requerimientos) deben establecerse las reglas básicas. Se
llega a un acuerdo con los stakeholders en cuanto a la forma y
frecuencia de la retroalimentación durante el proceso de
‘elicitación’, así como también el mecanismo para verificar y
aprobar los resultados ‘elicitados’.
b) Realizar la actividad de ‘elicitación’.
 Propósito: Reunirse con los stakeholders para ‘elicitar’
información sobre sus necesidades.
 Descripción: Se realiza el evento de ‘elicitación’
(tormenta de ideas, grupos de opinión, entrevistas,
observación, prototipos, talleres de requerimientos), o
se lleva a cabo la ‘elicitación’ (análisis de documentos,

análisis de interfaces) o se distribuye (encuestas y
cuestionarios).
c) Documentar los resultados de la ‘elicitación’.
 Propósito: Registrar la información proporcionada por
los stakeholders para usarse en el análisis.
 Descripción: Se genera un resumen del resultado del
evento de ‘elicitación’ (tormenta de ideas, grupos de
opinión, entrevistas, observación, prototipos, talleres de
requerimientos), incluyendo asuntos no resueltos.
 Elementos.
La documentación puede tener varias formas, incluyendo:
 Documentos escritos que incluyan resultados,
tal como minutas de reuniones.
 Grabaciones visuales o de audio.
 Pizarrones (ya sea reales o virtuales) donde las
notas son retenidas hasta que son transferidas a
otros medios.
d) Confirmar los resultados de la ‘elicitación’.
 Propósito: Validar que los requerimientos declarados
expresados por los stakeholders coincidan con el
entendimiento del problema y las necesidades de los
stakeholders.
 Descripción: Algunas de las técnicas de ‘elicitación’ se
benefician de la revisión de salidas documentadas de la
‘elicitación’ con los stakeholders para asegurar que el
entendimiento de los Analistas de Negocio se ajusta a los
deseos o intenciones reales de los stakeholders.
4.8.Técnicas y herramientas de validación de requerimientos de software.
El propósito de la validación de los requerimientos es asegurar que todos
los requerimientos apoyen la entrega de valor a la empresa, cumplan con
sus metas y objetivos, y respondan a una necesidad de los stakeholders.
a) Descripción
La validación de los requerimientos es un proceso continuo para asegurar que
los requerimientos de los stakeholders, de la solución, y de transición se
alinean con los requerimientos del negocio.
El evaluar cuál será el resultado para los stakeholders cuando su necesidad se
ha cumplido puede ser útil a la hora de validar los requerimientos. La
implementación de los requerimientos como un todo debe ser suficiente para
lograr ese estado futuro deseado para los clientes y usuarios. En muchos
casos, los stakeholders tendrán necesidades diferentes, necesidades
conflictivas y expectativas que pueden estar expuestas a través del proceso
de validación y necesitarán ser reconciliadas.
b) Elementos
 Identificar supuestos: En muchos casos puede que no sea posible
demostrar que la implementación del requerimiento resultará en el
beneficio deseado.
 Definir criterios medibles de evaluación: Si bien los beneficios de
negocio previstos se definen en el caso de negocio, los criterios
específicos de medidas y el proceso de evaluación pueden no haber sido
incluidos.
 Determinar el valor del negocio: El caso de negocio define el valor
entregado por una solución que satisface el alcance de la solución, pero
también es posible evaluar características o requerimientos individuales
para determinar si también ofrecen un valor de negocio.
 Determinar las dependencias para la realización de beneficios: No
todos los requerimientos contribuyen directamente al resultado final
deseado por la organización y descrito en el caso de negocio.
 Evaluar la alineación con el caso de negocio y el costo de
oportunidad: Un requerimiento puede ser de valor para un stakeholder
y aun no ser una parte deseable de una solución. Un requerimiento que
no está alineado con el caso de negocio debería ser definido y aprobado
en un caso de negocio aparte, o ser considerado para su eliminación del
alcance de la solución.
c) Técnicas
 Definición de los criterios de aceptación y evaluación: Los criterios
de aceptación son las métricas de calidad que deben alcanzarse para
lograr la aceptación por un stakeholder.
 Métricas e indicadores clave de desempeño: Usados para seleccionar
las medidas de desempeño apropiadas para la solución, componente de
la solución, o requerimiento.
 Prototipos: Los prototipos de componentes de productos se utilizan para
obtener el acuerdo del usuario con la solución propuesta.

 Análisis de los riesgos: El ‘análisis de los riesgos’ puede ser usado para
identificar posibles escenarios que pudieran alterar el valor entregado por
un requerimiento.
 Revisión estructurada: Se llevan a cabo reuniones de revisión para
confirmar si el stakeholder está de acuerdo en que sus necesidades están
cubiertas.
V. Calidad de software en etapas tempranas.
5.1.Definición de Calidad
“Conjunto de propiedades y características de un producto o servicio que
le confieren su aptitud para satisfacer unas necesidades explícitas o
implícitas.” ISO 8402.
“Concordancia con los requisitos funcionales y de rendimiento
explícitamente establecidos con los estándares de desarrollo
explícitamente documentados y con las características implícitas que se
espera de todo software desarrollado profesionalmente” Pressman (1992).
“Calidad es la idoneidad de uso. Es decir, las características del producto
que satisfacen las necesidades del cliente y, por tanto, producen
satisfacción de producto. La calidad es la inexistencia de deficiencias”
Juran “La calidad se define, desde el punto de vista del cliente, como
cualquier cosa que aumenta su satisfacción” Deming “Nivel al que una
serie de características inherentes satisfacen los requisitos” ISO 9000:
2000
“La capacidad de un conjunto de características inherentes de un producto,
componente del producto, o proceso, de satisfacer por completo los
requisitos del cliente” CMMI® (S.E.I.).
5.2.Gestión efectiva de la calidad del producto
Ilustración 1: Fuente: CURSO DE CALIDAD DE UN
Como se ve en la figura anterior, la gestión de calidad del producto es un
proceso que va en paralelo con el ciclo de vida del producto:
a) Durante la etapa de planificación.
o Los requisitos tienden a evolucionar con el tiempo por lo que es
importante llevar a cabo una gestión de los mismos. También hay
que especificarlos de forma clara y precisa. (Gestión de requisitos).
o También es importante establecer una buena estrategia de pruebas.
b) La siguiente fase de desarrollo es el diseño del producto que trae
consigo el diseño de casos de pruebas.
c) Durante las siguientes fases de codificación y pruebas del producto
se ejecutan las pruebas unitarias de sistemas, de integración, etc.

d) Una vez que el software ha superado las pruebas oportunas, se
libera el producto, gestionando antes su puesta en marcha para verificar
que su calidad es la adecuada.
Encontrar defectos desde las primeras etapas tempranas del proceso de
desarrollo permite su pronta corrección y que el resto de fases no se
desvíen de la previsión inicial, de modo que se satisfaga finalmente tanto
a las personas de negocio como a los clientes.
VI. Trazabilidad de requerimientos de software.
La Trazabilidad de requisitos es la asociación de un requisito con otros requisitos y
las diferentes instancias o artefactos con que se relaciona, así como la habilidad de
describir y seguir el ciclo de vida completo de un requisito, desde su origen, pasando
por su desarrollo y especificación y finalizando con su despliegue.
Es importante identificar y establecer el nivel de detalle que se requiere hacia los
diferentes casos de uso, reglas de negocio, características y atributos. Es necesario
seleccionar aquellas asociaciones que son de interés relevante para el análisis, para
su posterior análisis ante un posible cambio en los elementos que se puedan ver
afectados. Debido a esto, resulta fundamental que la trazabilidad siempre esté
actualizada y refleje la realidad del proyecto en tiempo real.
Disponer de una buena trazabilidad de requisitos nos permite realizar el control y
apoyo para la toma de decisiones en el proyecto. Por ejemplo, una de las ventajas
principales que nos ofrece la trazabilidad es poder determinar si todos los requisitos
han sido considerados y si las instancias que han sido generadas pueden asociarse
con un requisito válido.

a) La Matriz de Trazabilidad de Requisitos del Proyecto en el PMBOK.
Según el PMBOK la matriz de trazabilidad de requisitos es una tabla que vincula
los requisitos con su origen. Luego los monitorea durante la evolución del
proyecto.
La matriz de trazabilidad de requisitos del proyecto es una herramienta que nos
permite vincular los requisitos del producto, desde su concepción, hasta los
entregables de Proyecto que los satisfacen
 La versión previa de la matriz. Es previa al kick off. Se hace una vez
que ha sido aprobada la definición del alcance del proyecto y el listado
inicial de requisitos. Especifica la relación entre los requisitos y sus
especificaciones. Ayuda a confirmar que cada requisito agregue valor,
asociándolos a los objetivos de la organización y del proyecto.
 La versión posterior de la matriz. Su objetivo es la gestión de los
requisitos. Permite monitorear cada uno de los requisitos durante el ciclo
de vida del proyecto para asegurar que se están cumpliendo de manera
eficaz. Ayuda a detectar el impacto de cualquier cambio, o desviación de
la linea base del alcance, sobre los objetivos del proyecto. Es una
herramienta para administrar los cambios en el alcance, controlar de
calidad y la ejecución de las actividades.

VII. Marco Metodológico
7.1.Modelar el negocio.
7.2.Modelar la arquitectura de negocio.
Se diagramó los procesos Core y de apoyo de la idea de negocio trueque
(cambio de divisas).
Proceso core
7.3. Modelar la arquitectura de datos.
Modelo lógico
Modelo físico
IDEA DE
ID DESCRIPCIÓN
NEGOCIO
Usuario y contraseña para iniciar sesión del

001 Login
servicio.
002 Cliente Usuario a quien se le brinda el servicio
003 Tipo de cliente Personas naturales o jurídicas
La cuenta del cliente se recoge los derechos de

004 Cuenta del Cliente
cobro derivados del servicio.
Operación bancaria que consiste en cambiar

005 Transferencia
dinero de una cuenta a otra.
Tipo de Se estructura según criterios geográficos
006
Transferencia (nacionales, exteriores).
Número de cuenta al cual el cliente hará la

007 Cuenta de empresa
transferencia.
008 Banco Entidad financiera
009 Moneda Cualquier forma de dinero
010 Valor de cambio Valor por el intercambio de moneda
011 Cambio Dar o tomar monedas por sus equivalentes.
 Lineamiento de Datos
o Base de datos operacionales o procesamiento de transacciones
-OLTP.
o La base de datos debe ser relacional.
o La base de datos utilizara el motor de SQL server Enterprise
2017.
o Distribución de datos Descentralizada. Se hará replicación de
datos para mayor integridad y seguridad de los datos de los
usuarios.
o Solo el DBA debe tener acceso a los datos en el entorno de
Producción.
 Seguridad.
o La información del usuario (Claves, tarjetas frecuentes) debe estar
encriptada.
o Se usarán los servicios de seguridad que brinda Microsoft Azure
para proteger la información de los usuarios.

7.4.Modelar la arquitectura de aplicaciones.
Diagrama de despliegue de la solución, considerando sus dependencias

con medios de pago, sistemas de validación de antecedentes penales,
judiciales, en general sistemas externos que dependa de su plataforma.
 Lineamiento de Programación:
 Lenguaje de Programación: Angular 8, Type Script (Web application),

Dark (Mobile application) y C#.
 Frameworks: Flutter 1.8 para aplicaciones móviles multiplataforma,

ASP.NET CORE.
 Formato de transferencia de datos será en JSON-RPC.
 Se deberá usar patrones de diseño de software para una mayor

integración y robustez del sistema.
 Cada paquete de código deberá tener un controlador de versiones, para
este caso se usará Git.
ARQUITECTURA DE TECNOLOGÍA.
 Lineamiento de Arquitectura tecnológica:

 Se utilizará Windows server 2016, como sistema base para ejecutar los
diferentes servicios.
 Se utilizará la tecnología Azure Kubernetes Service, para agrupar y
administrar los diferentes microservicios.
 Azure Load Balancer el equilibrador de carga enruta el tráfico de internet a
la entrada.
 Se usarán contenedores para los microservicios.
 Se usarán patrones de cloud para mejorar la seguridad.
DIAGRAMA DE JUSTIFICACIÓN DE LAS TECNOLOGÍAS HABILITADORA
 Características Blockchain privado QUORUM.
 La blockchain de Ethereum “centrada-en-la-empresa, Quorum es una

creación de JP Morgan, que quiere avanzar en la tecnología de blockchain en
la industria financiera.
 La información es privada no se muestra ningún nodo de los participantes,
ya que esta encriptada.
 Mejora la privacidad de los contratos y las transacciones.
 Mejor desempeño.
 Gestión adecuada de pares y redes.
 Mecanismos de consenso basados en la votación.
7.5.Desarrollar los prototipos de la Aplicación
RECUPERAR
CONTRASEÑA
 Caso de Uso: Login
Caso de Uso Login
Versión 1.0
Actor Cliente
Descripción El cliente deberá de iniciar sesión en la aplicación
El cliente será autentificado con su nombre de usuario y
Precondición contraseña respetiva, además por seguridad se le
pedirá que ingrese un código que cambiara cada 15s
para mejorar la seguridad.
Paso Acción
Secuencia 1 El cliente inicia la aplicación, y espera que
Normal aparezca la pantalla de logeo.
2 El sistema solicita el ingreso de nombre de
usuario y contraseña.
3 El cliente deberá ingresar los datos solicitados y
presionar en el botón de ingresar.
4 El sistema solicitará el ingreso de un código de
6 dígitos, que será generado por mensaje de
texto o por los servicios de Google
Authenticator.
5 El cliente ingresara el código
6 El sistema confirma el ingreso del cliente a la
plataforma
Postcondición El cliente a ingresado a la aplicación y ya puede realizar

operaciones
Excepciones Paso Acción
Si <nombre de usuario y contraseña están
1 incorrectos>
El sistema notificara que el usuario y
contraseña son incorrectas
Si <Código de seguridad es incorrecto o
2 vencido>
El sistema notificara que hay un error de código
de acceso, pedirá que ingrese código
nuevamente.
Frecuencia esperada <nº de veces>
Importancia {importante}
Urgencia {no hay presión}
Comentarios Los nombres de usuarios y contraseñas tendrán un
patrón mínimo que cumplir según reglas de negocio.
 Caso de Uso: Registro de Datos Personales.
Caso de Uso Registro De Datos Personales
Versión 1.0
Actor Cliente
Descripción El cliente deberá proporcionar los datos necesarios que
el sistema solicite.
Si es la primera vez que el cliente va a realizar una
Precondición operación, es necesario que ingrese sus datos
personales, afines de cumplir con las normas legales y
reglas de negocio.
Paso Acción
Secuencia 1 El cliente selecciona un tipo de operación.
Normal 2 El sistema solicita el ingreso de los datos
personales a través de un formulario.
3 El cliente deberá de ingresar su DNI.
4 El sistema verificara y comprobara los datos a
través de la API de la Reniec.
5 El cliente ingresara información adicional que el
sistema solicite.
6 El Cliente deberá de hacer Click en boten de
registro.
Postcondición El cliente ahora podrá realizar cualquier operación

dentro de las opciones del sistema.
Si <Datos no coinciden >
1 El sistema evaluara el posible baneo de la
aplicación al cliente.
Frecuencia esperada <una vez>

Comentarios Adicional se añadirá una opción de subir una selfie, la
misma que será comparada con la foto de la dni para
encontrar patrones de identificación de rostro.
 Caso de Uso: Seleccionar Operación
Caso de Uso Seleccionar Operación
Versión 1.0
Actor Cliente
Descripción El cliente deberá seleccionar una operación que desea
realizar según las opciones de la pantalla de la
aplicación.
Para poder elegir una de las operaciones, primero
Precondición debería de cumplir con el caso de uso de registro de
datos personales.
Secuencia Paso Acción
Normal 1 El cliente elije una opción
2 El sistema mostrara la pantalla solicitada
Postcondición El sistema mostrara las pantallas requeridas según el
tipo de operación a realizar
Si <nombre de usuario y contraseña están
1 incorrectos>

Importancia {opcional}
Comentarios
 Caso de Uso: Registrar Monto
Caso de Uso Registrar Monto

Versión 1.0
Actor Cliente
Descripción El cliente deberá de ingresar monto de requerido por el
sistema
El cliente deberá usar el caso de uso de selección de
Precondición operación primero, luego acceder a las pantallas
requeridas.
Paso Acción
Secuencia 1 El cliente ingresa un monto en el formulario de
Normal ingreso.
2 El sistema evaluara si es un monto valido.
3 El sistema evaluara los datos de la persona
Postcondición El cliente ahora podrá proceder con las operaciones

necesarias.
Si <monto es incorrecto>
1 El sistema notificara que el monto ingresado es
incorrecto.
Si <Monto mínimo>
2 El sistema notificara que el monto ingresado es
demasiado bajo para realizar la operación
Comentarios
 Caso de uso: Transferencia.
Caso de Uso Transferencia
Versión 1.0
Actor Cliente, Trueq
Descripción El cliente realiza una transferencia para el intercambio
de divisas.
El Cliente antes de realizar la transferencia, primero
Precondición deberá usar el caso de uso Registrar monto.
Paso Acción
Secuencia 1 El sistema muestra los términos y condiciones
Normal de servicio.
2 El Cliente deberá de leer los términos y
condiciones.
3 El sistema mostrara un mensaje solicitante la
aceptación de los términos y condiciones.
4 El cliente confirma la transferencia.
5 El sistema muestra las opciones de los tipos de
tarjetas disponibles
6 El cliente elige una tarjeta de donde desea
enviar el dinero a la plataforma.
7 El sistema solicita el ingreso de los datos de la
tarjeta.
8 El cliente introduce los datos solicitados por la
aplicación
9 El sistema se comunica con la API de proceso
de pagos.
10 El Cliente es notificado de que la transferencia
se ha hecho correctamente.
11 El sistema informa que el cliente debe esperar
el tiempo estimado en los términos de servicio.
12 El sistema genera baucher de la operación.
Postcondición El cliente recibe el monto en la moneda solicitada.
SI <Tarjeta ingresada no es Valida>
1 El sistema notificara que el motivo de rechazo
de la tarjeta ingresada.
SI <Saldo de Tarjeta Insuficiente>
2 El sistema notificara el error correspondiente
con el tipo de excepción ejecutada.
Importancia {Critica}
Urgencia {alta}
Comentarios Las transferencias se harán bajo el registro del sistema
de blockchain para mejorar la seguridad de las
transacciones financiera
 Caso de uso: Consultar Conversión.
Caso de Uso Consultar Conversión
Versión 1.0
Actor Cliente
Descripción El cliente realiza una cotización de las tasas de
conversión.
El Cliente antes de realizar la cotización, primero
Precondición deberá usar el caso de uso Registrar monto y
Seleccionar Operación.
Paso Acción
Secuencia 1 El cliente ingresa el monto y elige la moneda
Normal que desea retornar.
2 El sistema valida los datos ingresados.
3 El sistema se comunica con la API de tasa de
cambio actual en tiempo real.
4 El sistema muestra la información solicitada por
el cliente
5 El cliente debe elegir si desea imprimir los
resultados
6 El sistema guardara la información en formato
pdf
Postcondición El cliente recibe el monto en la moneda solicitada.

2
Comentarios
 Documentación de Pantalla de inicio.
Ilustración 2 Pantalla de Inicio.
PANTALLA DE LOGIN
Titulo de Aplicación
Control Widget: MyAppBar title Theme.of(context).primaryTextTheme.title
"TRUEQ" style
BOTON INGRESAR
ControlWidget: RaisedButton title "ingresar"evento onPressed:PantallaLogeo()
/': (context) => PantallaLogeo()
routes
DescripcionBoton para ingresar a la pantalla de logeo y autentificaciòn de usuario.
BOTON REGISTRARTE
ControlWidget: RaisedButton title evento onPressed:PantallaRegistro()
"Registrarse"
routes/': (context) => PantallaRegistro()
DescripcionBoton para ingresar a la pantalla de registro de usuario.
 Documentación de la pantalla de Login(Ingreso a la aplicación).
PANTALLA DE LOGIN
Control Widget: MyAppBar title "TRUEQ" Theme.of(context).primaryTextTheme.title
style
IMAGEN USUARIO
Control Widget: Image.asset alignment: Alignment.topCenter Width: 300 Height: 300
CANPO DE TEXTO: Email

Control Widget: FieldText labelText: ingresar Correo'
Tipe Email
Descripcion Campo de texto que solo acepta email esta validado por el mismo control, el usuario debe ingresar su correo
CANPO DE TEXTO: Password

Control Widget: FieldText labelText: ingresar Correo'
Tipe Password
Descripcion Campo de texto password esta validado por el mismo control, el usuario debe ingresar su contraseña
BOTON INGRESAR
Control Widget: RaisedButton title "Registrarse" evento onPressed:PantallaRegistro()
routes /principal': (context) => PantallaPrincipal()
DescripcionBoton para ingresar a la pantalla primcipal de la aplicacion.
 Documentación de la pantalla Registro de Usuario.
PANTALLA DE REGISTRO
Control Widget: MyAppBar title Theme.of(context).primaryTextTheme.title
"TRUEQ" style
CANPO DE TEXTO: Nombres

Control Widget: FieldText labelText: Nombres'
Tipe Text
Descripcion Campo de texto, el usuario debe ingresar su nombres
CANPO DE TEXTO: Apellidos

Control Widget: FieldText labelText: Apellidos'
Tipe Text
Descripcion Campo de texto, el usuario debe ingresar sus apellidos
CANPO DE TEXTO: Documento de Indentidad

Control Widget: FieldText labelText: Dni'
Tipe Text
Descripcion Campo de texto, el usuario debe ingresar su documento de dni
CANPO DE TEXTO: Correo

Control Widget: FieldText labelText: 'Email'
Tipe Text
Descripcion Campo de texto, el usuario debe ingresar su email
CANPO DE TEXTO: Numero de Celular
Control Widget: FieldText labelText: Celular'
Tipe Text
Descripcion Campo de texto, el usuario debe ingresar su numero de celular
CANPO DE TEXTO: Ocupacion
Control Widget: FieldText labelText: Ocupacion'
Tipe Text
Descripcion Campo de texto, el usuario debe ingresar su Ocupcion
CANPO DE TEXTO: Fecha Naciminto
Control Widget: FieldText labelText: Fecha Nacimiento'
Tipe Date
Descripcion Campo de texto, el usuario debe ingresar su Fecha Nacimiento
BOTON REGISTRAR
Control Widget: RaisedButton title "Registrarse"evento onPressed:PantallaRegistro()
routes /principal': (context) => PantallaPrincipal()
DescripcionBoton para enviar los datos del formulario a la base de dagtos.
7.6.Desarrollar Modelos de Secuencia.
REFERENCIS
Castaño, S., & Varon G, Y. (2017). Arquitectura Empresarial de la Agencia Nacional de

Infraestructura - ANI. Obtenido de Escuela Colombiana de ingenieria JulioGaravito:
https://repositorio.escuelaing.edu.co/bitstream/001/690/2/Var%C3%B3n%20G.%2C%
20Yenny%20Paola%20-%202017.pdf
Casusol, M., & Ramirez, C. (2017). Propuesta de una Arquitectura Empresarial para la.
Obtenido de Universidad Peruana de Ciencias Aplicadas, Lima,:
https://repositorioacademico.upc.edu.pe/bitstream/handle/10757/625258/JANCACH
AGUA_SP.pdf?sequence=1&isAllowed=y
Emprendedores. (24 de Mayo de 2019). ¿Qué significa modelo de negocio? Obtenido de

Emprendedores: https://www.emprendedores.es/crear-una-empresa/a69057/que-
significa-modelo-de-negocio/
EvaluandoSoftware. (10 de Febrero de 2016). Arquitectura empresarial ¿qué es y para que

sirve? Obtenido de Evaluando Software:
https://www.evaluandosoftware.com/arquitectura-empresarial/
Josey, A., Harrison, H. P., Rouse, M., & Van Sante, T. (2013). TOGAF Version 9.1. Obtenido de
LUT School of Business:
https://www2.it.lut.fi/wiki/lib/exe/fetch.php/courses/cs30a7400/i112.pdf
Karel, g. (27 de julio de 2017). Top 5 Metodologías de Desarrollo de Software. Obtenido de

Mega Practtical (Soluciones de Negocio): https://www.megapractical.com/blog-de-
arquitectura-soa-y-desarrollo-de-software/metodologias-de-desarrollo-de-software
Mary, T. (2017). CICLO DE VIDA DE SOFTWARE. Obtenido de CALAMÉO:

https://es.calameo.com/books/003285581c078a5847539
MiCarreraUniversitaria. (2018). Ingeniería de software: Qué es, objetivos, características y más.

Obtenido de Mi carrera universitaria: https://micarrerauniversitaria.com/c-
ingenieria/ingenieria-de-software/
OKHosting. (2018). El ciclo de vida del software. Obtenido de OKHosting:

https://okhosting.com/blog/el-ciclo-de-vida-del-software/
Sara, K. W. (30 de Enero de 2018). ¿Qué es TOGAF? Una metodología de arquitectura

empresarial para negocios. Obtenido de España CIO:
https://www.ciospain.es/finanzas/que-es-togaf-una-metodologia-de-arquitectura-
empresarial-para-negocios
TutorialsPoint. (2019). Software - Ciclo de Vida de Desarrollo. Obtenido de TutorialsPoint:

https://www.tutorialspoint.com/es/software_engineering/software_development_life
_cycle.htm
International Institute of Business Analysis. (2009). A guide to the Business Analysis Body of
Knowledge (BABOK guide), version 2.0. Toronto: International Institute of Business
Analysis.
Mangialomini, J. (7 de Marzo de 2017). Medium. Obtenido de Introducción a los Frameworks

de Escalado Ágil: https://medium.com/@jmangialomini/introduccion-a-los-entreprise-
agile-frameworks-4ea786f192d8
Pressman, R. S. (2010). Ingeniería del Software: Un Enfoque Práctico. México: McGRAW-HILL.
Project Management Institute. (s.f.). Obtenido de Disciplined Agile:

http://disciplinedagiledelivery.com/introduction-to-dad/
The LeSS Company B.V. (s.f.). The LeSS Company B.V. Obtenido de Introducción a LeSS:
https://less.works/less/framework/introduction.html

Informe

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Informe

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA ARQUITECTURA Y

ESCUELA PROFESIONAL DE INGENIERÍA DE

IDEA DE NEGOCIO - TRUEQ

RIMRACHIN ESCRIBANO, RUT

VALLEJOS RAMOS, FERNANDO

PISFIL SUGARAY, ESTUARDO

CALDERON PIZANGO, FLAVIO

ING. VÍCTOR TUESTA MONTEZA

mercado de las enormes estrategias de negocio. Las grandes organizaciones

que aplican arquitectura empresarial reflejan mejoras y beneficios en sus

procesos de negocio cuando alinean la tecnología a sus objetivos estratégicos.

Cuando no integran las aplicaciones, información, procesos y tecnología a los

objetivos estratégicos, suele desperdiciar muchos recursos y afectar más a su

competitividad. Por esto es necesaria la integración a través de un framework

togaf de arquitectura empresarial que permita a la empresa asumir de la mejor

forma posible los continuos cambios.

En este proyecto se describe la investigación aplicada a una idea de negocio

de cambio de divisas, donde se diseñó arquitectura empresarial aplicable al

El objetivo general de este proyecto consistió en el diseño de arquitectura

empresarial aplicable a la idea de negocio Trueq con el fin de que se considere

la importancia de la implementación de arquitectura empresarial en

Arquitectura Empresarial, Arquitectura de negocio, arquitectura tecnológica,

Las aplicaciones móviles en la actualidad son muy utilizadas gracias a las

facilidades de acceso a internet existentes, así como los avances tecnológicos

de teléfonos inteligentes, estos cuentan con sistemas operativos que facilitan

desarrollar aplicaciones gratuitas que se pueden instalar en un dispositivo

la tecnología se propuso una aplicación móvil para la publicación,

autentificación y marketing digital, de proyectos, ya sean de investigación o

una simple propuesta de negocio, dando la facilidad a los usuarios de

interactuar desde el sitio que se encuentre.

Existen ideas de nuevos profesionales o de personas emprendedoras, que no

se han realizado, muchas por falta de dinero o de estrategias que permitan el

surgimiento de la misma. También existen inversionistas que cuentan dinero

Ante la situación y aprovechando los grandes beneficios que brinda el uso de

tecnologías, esta startup a realizar se enfoca en ayudar a emprendedores a

publicar sus ideas y a inversionistas interactuar con los autores de la idea de

su interés e invertir, evitando entrevistas que demandan tiempo, además estas

ideas cargadas a la aplicación tienen acceso al marketing digital que sea de su

preferencia el cuál será presentado en distintos paquetes de adquisición, como

factor monetario de la startup.

requerimientos y los procesos que incluye la misma. Ha sido elaborado por

estudiantes de Ingeniería de Sistemas de la Universidad Señor de Sipán.

Realizar un análisis de requerimientos para diseñar el sistema Trueq’.

o Construir el marco teórico.

o Modelar la arquitectura de negocio.

o Modelar la arquitectura de datos.

o Modelar la arquitectura de aplicaciones.

o Desarrollar los prototipos de la Aplicación.

o Desarrollar Modelos de Secuencia.

o Desarrollar la base de datos.

o Validar los Requerimientos.

4.1. Modelos de negocio

Un modelo de negocio es una herramienta previa al plan de negocio que

a hacer, a quién se lo vas a vender, cómo se lo vas a vender y de qué forma

vas a generar ingresos. Es una herramienta de análisis que te permitirá

de ingresos vas a tener. (Emprendedores, 2019)

La arquitectura empresarial en una organización corresponde a la forma de

representar de manera integral la empresa, permitiendo cubrir y considerar

de negocio en la empresa, comenzando desde la perspectiva estratégica

(misión, visión, lineamientos e indicadores estratégicos), hasta llegar a una

estructura actual y futura para los procesos de la organización; la cual

incorpora algunos de los componentes que se consideran como críticos

o Los procesos: modelos de negocio y procesos.