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)

[Link] 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)
[Link] 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)

[Link]í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.

(TutorialsPoint, 2019)
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.

(TutorialsPoint, 2019)

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.

(TutorialsPoint, 2019)

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.

[Link]í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.

[Link]ó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.).

[Link]ó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

[Link] el negocio.

[Link] 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.

 [Link] 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,

[Link] 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.
[Link] 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.
Excepciones Paso Acción
Si <Datos no coinciden >
1 El sistema evaluara el posible baneo de la
aplicación al cliente.

Frecuencia esperada <una vez>

Importancia {importante}
Urgencia {no hay presión}
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
Excepciones Paso Acción
Si <nombre de usuario y contraseña están
1 incorrectos>

Frecuencia esperada <nº de veces>

Importancia {opcional}
Urgencia {no hay presión}
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.
Excepciones Paso Acción
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
Frecuencia esperada <nº de veces>
Importancia {importante}
Urgencia {no hay presió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.
Excepciones Paso Acción
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.
Frecuencia esperada <nº de veces>
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.

Excepciones Paso Acción

2
Frecuencia esperada <nº de veces>
Importancia {importante}
Urgencia {no hay presión}
Comentarios
  Documentación de Pantalla de inicio.

Ilustración 2 Pantalla de Inicio.

PANTALLA DE LOGIN
Titulo de Aplicación
Control Widget: MyAppBar title [Link](context).[Link]
"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
Titulo de Aplicación
Control Widget: MyAppBar title "TRUEQ" [Link](context).[Link]
style

IMAGEN USUARIO
Control Widget: [Link] alignment: [Link] 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
Titulo de Aplicación
Control Widget: MyAppBar title [Link](context).[Link]
"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.
[Link] 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:
[Link]
20Yenny%20Paola%20-%[Link]

Casusol, M., & Ramirez, C. (2017). Propuesta de una Arquitectura Empresarial para la.
Obtenido de Universidad Peruana de Ciencias Aplicadas, Lima,:
[Link]
AGUA_SP.pdf?sequence=1&isAllowed=y

Emprendedores. (24 de Mayo de 2019). ¿Qué significa modelo de negocio? Obtenido de

Emprendedores: [Link]
significa-modelo-de-negocio/

EvaluandoSoftware. (10 de Febrero de 2016). Arquitectura empresarial ¿qué es y para que

sirve? Obtenido de Evaluando Software:
[Link]

Josey, A., Harrison, H. P., Rouse, M., & Van Sante, T. (2013). TOGAF Version 9.1. Obtenido de
LUT School of Business:
[Link]

Karel, g. (27 de julio de 2017). Top 5 Metodologías de Desarrollo de Software. Obtenido de

Mega Practtical (Soluciones de Negocio): [Link]
arquitectura-soa-y-desarrollo-de-software/metodologias-de-desarrollo-de-software

Mary, T. (2017). CICLO DE VIDA DE SOFTWARE. Obtenido de CALAMÉO:

[Link]

MiCarreraUniversitaria. (2018). Ingeniería de software: Qué es, objetivos, características y más.

Obtenido de Mi carrera universitaria: [Link]
ingenieria/ingenieria-de-software/

OKHosting. (2018). El ciclo de vida del software. Obtenido de OKHosting:

[Link]

Sara, K. W. (30 de Enero de 2018). ¿Qué es TOGAF? Una metodología de arquitectura

empresarial para negocios. Obtenido de España CIO:
[Link]
empresarial-para-negocios

TutorialsPoint. (2019). Software - Ciclo de Vida de Desarrollo. Obtenido de TutorialsPoint:

[Link]
_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: [Link]
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:

[Link]

The LeSS Company B.V. (s.f.). The LeSS Company B.V. Obtenido de Introducción a LeSS:
[Link]