Proyecto Final Software 2

Página |1
UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO
FACULTAD DE INGENIERIA EN CIENCIAS DE LA COMPUTACION Y

TELECOMUNICACIONES
GRUPO # 9
INGENIERÌA DE SOFTWARE II
“APLICACIÓN MÓVIL DE ABASTECIMIENTO DE

INVENTARIOS MEDIANTE EL USO DE SMART
CONTRACTS PARA LA EMPRESA CONINCO SRL”
ESTUDIANTES:
 MELENDEZ MARTINEZ SERGIO DRISS 215049187

 ZAMBRANA GARCIA VICTOR VALENTIN 214029050
SIGLA: INF 512 - SB
FECHA: 14/07/2022
Contenido
Página |2
Capítulo 1: Plan de Administración del Proyecto.................................................................11

1.1 Introducción.............................................................................................................................11
1.2 Objetivos..................................................................................................................................11
1.2.1 Objetivo general.....................................................................................................................11
1.2.2 Objetivos específicos........................................................................................................12
1.3 Alcance....................................................................................................................................12
1.3.1 Módulo Usuario................................................................................................................12
1.3.2 Módulo Producto..............................................................................................................13
1.3.3 Módulo Inventario............................................................................................................13
1.4 Fundamentación Teórica.........................................................................................................13
1.4.1 Metodología Ágil.............................................................................................................13
1.4.1.1 Propósito de SCRUM...................................................................................................13
1.4.1.2 Equipo de SCRUM.......................................................................................................14
1.4.1.3 Ingeniería de Software Asistida por Computadoras.....................................................15
1.4.1.4 Ingeniería basada en Componentes.....................................................................................16
1.4.1.5 Smart Contracts...................................................................................................................18
1.5 Propósito del Plan del Proyecto...............................................................................................19
1.6 Métricas en el Software...........................................................................................................20
1.7 Análisis de Riesgo...................................................................................................................21
1.8 Tabla de Recursos....................................................................................................................22
1.9 Organización Interna...............................................................................................................23
1.10 Mecanismos de Seguimiento y control....................................................................................24
Capítulo 2: Modelos de Desarrollo de Software...................................................................26
2.1 Modelo de Contexto General...................................................................................................26
2.2 Modelo de Arquitectura...........................................................................................................27
7.2.1 Diseño de la arquitectura lógica.......................................................................................27
7.2.2 Diseño de la arquitectura física........................................................................................27
2.3 Modelo de Datos......................................................................................................................28
2.4 Marco de Trabajo de Desarrollo Scrum...................................................................................28
2.4.1 Personas y roles del proyecto...............................................................................................28
2.4.2 Sprint Planning Meeting (Reunión de Planeamiento del Sprint).........................................28
2.4.2.1 Pila del Sprint (Sprint Backlog) Sprint 0..........................................................................30
2.4.2.2 Reunión Diaria (Daily Scrum).........................................................................................32
2.4.2.3 Sprint Review...................................................................................................................32
Página |3
2.4.2.4 Sprint Retrospective.........................................................................................................33

2.4.3 Sprint 1.................................................................................................................................33
2.4.3.1 Personas y roles del proyecto...........................................................................................33
2.4.3.2 Planeación de la Iteración del Sprint (Product Backlog).................................................34
2.4.3.3 Historias de Usuario.........................................................................................................34
2.4.3.4 Sprint Planning Meeting...................................................................................................35
2.4.3.5 Daily Scrum......................................................................................................................36
2.4.3.7 BurnDown........................................................................................................................37
2.4.3.8 Sprint Review...................................................................................................................38
2.4.4 Sprint 2.................................................................................................................................38
2.4.4.1 Personas y roles del proyecto...........................................................................................38
2.4.4.2 Planeación de la Iteración del Sprint (Product Backlog).................................................38
2.4.4.3 Historias de Usuario.........................................................................................................39
2.4.4.4 Sprint Planning Meeting...................................................................................................40
2.4.4.5 Daily Scrum......................................................................................................................40
2.4.4.7 BurnDown........................................................................................................................42
2.4.4.8 Sprint Review...................................................................................................................42
Capítulo 3: Manual de Calidad.............................................................................................45
3.1 Introducción a la guía del SQA...............................................................................................45
3.1.1 Introducción.........................................................................................................................45
3.1.2 Objetivo General del plan SQA...........................................................................................46
3.1.2.1 Objetivos Específicos del Plan SQA................................................................................46
3.1.3 Misión..................................................................................................................................46
3.1.4 Visión...................................................................................................................................47
3.1.5 Políticas de Calidad..............................................................................................................47
3.1.6 Eslogan.................................................................................................................................47
3.2 Plan de aseguramiento de calidad del Software......................................................................48
3.2.1 Propósito..............................................................................................................................48
3.2.2 Objetivo................................................................................................................................48
3.2.3 Descripción..........................................................................................................................48
3.2.4 Alcance.................................................................................................................................49
3.2.5 Documentos de Referencia..................................................................................................49
Página |4
3.3 Gestión.....................................................................................................................................50
3.3.1 Organización del cliente.......................................................................................................50
3.3.2 Organización del SQA.........................................................................................................50
3.3.3 Tareas...................................................................................................................................51
3.4 Documentación........................................................................................................................52
3.4.1 Especificación de requisitos de Software.............................................................................52
3.4.2 Descripción del Diseño del Software...................................................................................54
3.4.3 Plan de Verificación y validación........................................................................................56
3.4.3.1 Ciclo de vida de verificación y validación.......................................................................57
3.4.4 Informe de verificación y validación...................................................................................58
3.4.4.1 Reporte sumario de Fase V & V......................................................................................58
3.4.4.2 Reporte de Anomalías......................................................................................................59
# De Reporte:..................................................................................................................................60
3.4.4.3 Reporte final de V & V....................................................................................................61
# De Reporte:..................................................................................................................................61
3.4.5 Documentación del Usuario (UD).......................................................................................62
3.5 Estándares, prácticas y convenciones......................................................................................64
3.5.1 Estándar de codificación......................................................................................................64
3.5.2 Estándar de comentarios......................................................................................................66
3.5.3 Responsables de verificar el cumplimiento.........................................................................66
3.6 Revisiones................................................................................................................................66
3.6.1 Revisiones y auditorías........................................................................................................66
3.6.1.1 Revisión de los requisitos del Software (SRR)................................................................66
3.6.1.2 Revisión del Diseño Preliminar (PDR)............................................................................67
3.6.1.3 Revisión del Diseño Crítico (CDR)..................................................................................67
3.6.1.4 Revisión del Plan de Verificación y validación...............................................................68
3.6.1.5 Auditoría Funcional..........................................................................................................68
3.6.1.6 Auditoría Física................................................................................................................69
3.6.1.7 Auditorías del Proceso......................................................................................................70
3.6.1.8 Revisiones de gestión.......................................................................................................70
3.6.2 Evaluación de la calidad de los productos...........................................................................71
3.6.3 Revisar el ajuste al proceso..................................................................................................72
3.6.4 Revisión Técnica Formal.....................................................................................................72
3.6.5 Requerimientos mínimos.....................................................................................................73
Página |5
3.6.6 Agenda.................................................................................................................................73
Fase I – Inicial.................................................................................................................................73
Iteración I................................................................................................................................................73
3.7 Gestión de configuración.........................................................................................................74
3.8 Información sobre problemas y acción correctiva...................................................................74
# De Reporte:..................................................................................................................................75
3.9 Herramientas, técnicas y metodologías...................................................................................77
3.10 Control de código....................................................................................................................77
3.11 Control de medios....................................................................................................................78
3.11.1 Medio de Almacenamiento..................................................................................................78
3.11.2 Proceso de copias de seguridad............................................................................................79
3.11.3 Puntos de control..................................................................................................................79
3.12 Control de suministradores y subcontratos..............................................................................79
3.13 Recolección, mantenimiento y retención de registros.............................................................79
Capítulo 4: Modelos de Desarrollo en Formato Digital........................................................82
4.1 Herramientas Case...................................................................................................................82
4.1.1 Definición.............................................................................................................................82
4.2 Visual Studio Code..................................................................................................................83
4.2.1 Características......................................................................................................................84
4.3 Sparx Systems Enterprise Architect........................................................................................85
4.3.1 Características......................................................................................................................86
4.3.1.1 Gestión de Requisitos.......................................................................................................86
4.3.1.2 Modelización y análisis de negocios................................................................................86
4.3.1.3 Simulación........................................................................................................................86
4.3.1.4 Desarrollo del Sistema......................................................................................................87
4.4 Gestión de Pruebas..................................................................................................................88
4.5 Modelado de datos...................................................................................................................89
Capítulo 5: Aspectos Legales para la apertura de una empresa de Desarrollo.....................91
5.1 Aspectos legales a cumplir......................................................................................................91
5.2 Fundempresa............................................................................................................................91
5.2.1 Trámite de control de homonimia........................................................................................91
5.2.2 Requisitos.............................................................................................................................93
5.2.3 Inscripción de la empresa en el registro de comercio..........................................................93
5.3 Servicio de Impuestos Nacionales.........................................................................................100
Página |6
5.3.1 Requisitos...........................................................................................................................101
5.3.1.1 NIT.................................................................................................................................101
5.3.1.1.1 Régimen General............................................................................................................101
5.3.1.1.1.1 Persona Natural...........................................................................................................101
5.3.1.1.1.2 Personas Jurídicas.......................................................................................................102
5.3.1.1.1.3 Sucesión indivisa........................................................................................................102
5.3.1.1.2 Régimen Tributario Simplificado...................................................................................103
5.3.1.1.3 Régimen Tributario Integrado........................................................................................103
5.3.1.1.3.1 Personas naturales propietarias de hasta dos vehículos..............................................103
5.3.1.1.4 Régimen Agropecuario Integrado..................................................................................103
5.3.1.1.4.1 Personas Naturales......................................................................................................103
5.3.1.1.4.2 Cooperativas...............................................................................................................103
5.3.1.1.4.3 Sucesión Indivisa........................................................................................................104
5.3.1.2 Modificaciones al NIT....................................................................................................104
5.3.1.2.1 Datos Básicos – Personería Jurídica...............................................................................104
5.3.1.2.1.1 Razón Social...............................................................................................................104
5.3.1.2.1.2 Origen de entidad composición de capital..................................................................104
5.3.1.2.1.3 Fecha de reconocimiento de persona jurídica.............................................................104
5.3.1.2.1.4 Carácter de entidad.....................................................................................................105
5.3.1.2.2 Empresa natural a empresa unilateral.............................................................................105
5.3.1.2.3 Empresa unipersonal a empresa natural.........................................................................105
5.3.1.2.4 Modificación de régimen................................................................................................105
5.3.1.2.5 Actividades económicas.................................................................................................105
5.3.1.2.5.1 Alta o modificación de actividades.............................................................................105
5.3.1.2.5.2 Baja de actividades.....................................................................................................106
5.3.1.2.6 Características Tributarias..............................................................................................106
5.3.2 Gobierno Municipal...........................................................................................................108
5.3.3 Caja de Salud.....................................................................................................................111
5.3.4 AFPS..................................................................................................................................114
5.3.5 Fundempresa......................................................................................................................119
5.3.6 Derechos de autor a cumplir..............................................................................................121
Capítulo 6: Infraestructura para el desarrollo del Software................................................125
6.1 Gestión de la configuración del Software..............................................................................125
6.1.1 Propósito............................................................................................................................125
Página |7
6.1.2 Alcance...............................................................................................................................125
6.2 Ambientes Establecidos.........................................................................................................125
6.2.1 Ambiente de desarrollo......................................................................................................125
6.2.1.1 Generalidades.......................................................................................................................125
5.2.2.2 Descripción.....................................................................................................................126
Servidor.................................................................................................................................................126
6.2.2 Ambiente de pruebas..........................................................................................................127
6.2.2.1 Generalidades.................................................................................................................127
6.2.3 Ambiente de producción....................................................................................................128
6.2.3.1 Generalidades.................................................................................................................128
6.2.4 Herramientas para el control de versiones.........................................................................128
6.2.4.1 Git.........................................................................................................................................128
6.2.5 Consideraciones generales.................................................................................................130
Capítulo 7: Sitio Web de la empresa...................................................................................132
7.1 Desarrollo del Sitio Web.......................................................................................................132
Capítulo 8: Estudio del Mercado........................................................................................134
8.1 Objetivo del estudio...............................................................................................................134
8.2 Definición del producto.........................................................................................................134
8.3 Análisis de la demanda..........................................................................................................134
8.3.1 Distribución geográfica del mercado de consumo.............................................................134
8.3.2 Proyección de la demanda..................................................................................................134
8.4 Análisis de la oferta...............................................................................................................135
8.4.1 Proyección de la oferta.......................................................................................................135
8.4.2 Determinación de costo promedio.....................................................................................135
8.4.3 Canal de distribución.........................................................................................................136
8.4.4 Descripción de las decisiones tomadas..............................................................................136
Capítulo 9: Pruebas en el Software.....................................................................................138
9.1 Planificador de pruebas..........................................................................................................138
9.2 Iteración en PUDS.................................................................................................................138
9.2.1 Caso de Prueba...............................................................................................................139
9.3 Diseñador de pruebas.............................................................................................................139
9.3.1 Procedimiento de Prueba................................................................................................140
9.4 Método de la caja negra.........................................................................................................140
9.4.1 Procedimiento de Prueba................................................................................................141
Página |8
Capítulo 10: Marketing.......................................................................................................143

10.1 Introducción..............................................................................................................................143
10.2 Medios de propagación.............................................................................................................143
10.3 Decisiones de anuncios.............................................................................................................144
10.4 Metas de publicidad..................................................................................................................144
10.5 Diseño de publicidad................................................................................................................144
10.6 Elección de público...................................................................................................................145
10.7 Nombre, presupuesto y calendario...........................................................................................145
10.8 Inversión de anuncios...............................................................................................................145
10.9 Monitoreo de campaña.............................................................................................................145
10.10 Generación de informes..........................................................................................................146
10.11 Generación de informes..........................................................................................................146
Capítulo 11: Aspectos para la puesta en marcha.................................................................148
11.1 Firebase..................................................................................................................................148
11.1.1 Características....................................................................................................................148
11.2 Políticas de Privacidad de Nuestra Aplicación.........................................................................153
11.2.1.- Introducción.........................................................................................................................153
11.2.2.- Contenido............................................................................................................................154
11.2.3.- Modelo de Nuestra Política de Privacidad..........................................................................154
11.3 Infraestructura en Hardware.....................................................................................................162
11.4 Seguridad...............................................................................................................................162
11.5 Respaldos...............................................................................................................................163
11.6 Planes de contingencia...........................................................................................................164
Capítulo 12: Versión Operativa del Software.....................................................................167
12.1 Software terminado de acuerdo a los factores de calidad......................................................167
Seguridad..........................................................................................................................................167
Fiabilidad..........................................................................................................................................167
Disponibilidad...................................................................................................................................167
Mantenibilidad..................................................................................................................................167
Portabilidad.......................................................................................................................................167
Eficiencia..........................................................................................................................................167
Facilidad de Uso...............................................................................................................................168
Página |9
TABLA DE ILUSTRACIONES
ILUSTRACIÓN 1 MODELO DE CONTEXTO GENERAL................................................................................................................26

ILUSTRACIÓN 2 DISEÑO DE LA ARQUITECTURA LÓGICA........................................................................................................27
ILUSTRACIÓN 3 DISEÑO DE LA ARQUITECTURA FÍSICA..........................................................................................................27
ILUSTRACIÓN 4 MODELO DE DATOS.......................................................................................................................................28
ILUSTRACIÓN 5 SPRINT 1.........................................................................................................................................................37
ILUSTRACIÓN 6 SPRINT 2.........................................................................................................................................................42
ILUSTRACIÓN 7 CICLO DE VIDA SQA......................................................................................................................................46
ILUSTRACIÓN 8 ESLOGAN DE LA EMPRESA.............................................................................................................................48
ILUSTRACIÓN 9 ORGANIZACIÓN DEL CLIENTE.........................................................................................................................50
ILUSTRACIÓN 10 SECUENCIA DE TAREAS................................................................................................................................52
ILUSTRACIÓN 11 SENAPI 1.....................................................................................................................................................122
ILUSTRACIÓN 12 SENAPI 2.....................................................................................................................................................122
ILUSTRACIÓN 13 PÁGINA DE LA EMPRESA.............................................................................................................................132
ILUSTRACIÓN 14 CASO DE PRUEBA.......................................................................................................................................139
ILUSTRACIÓN 15 MÉTODO DE CAJA NEGRA..........................................................................................................................140
ILUSTRACIÓN 16 FIREBASE....................................................................................................................................................148
ILUSTRACIÓN 17 INFRAESTRUCTURA....................................................................................................................................162
ILUSTRACIÓN 18 SEGURIDAD................................................................................................................................................163
P á g i n a | 10
CAPÍTULO I:
PLAN DE ADMINISTRACIÓN DEL
PROYECTO
P á g i n a | 11
Capítulo 1: Plan de Administración del Proyecto
1.1 Introducción
Vivimos en una era digital en dónde cada vez el proceso para la realización de actividades
debería ser sistematizado, esto también incluye una gran diversidad de formas de pago, muchas
opciones de realizar compras, ventas e intercambios, muchas formas de llegar al producto final y la
relación entre el vendedor y el consumidor.
Es por ello que el proyecto toma como iniciativa añadir un nuevo método de adquisición de productos
en el inventario de una empresa, de una forma más segura y sin la necesidad de complicaciones, a esto
incluir todos aquellos procesos que toman demasiado tiempo para llegar a un acuerdo en común.
A través de investigaciones, se logró conseguir una información necesaria de todo el procedimiento
por el cuál los productos deben atravesar para poder llegar al propietario final de una forma segura y
sin obstáculos.
Nuestra aplicación tiene la finalidad de ser base para que las empresas tomen esta opción como una
forma de adquisición de sus productos en un futuro cercano, y así poder mejorar en muchos campos
entre ellos incluidos la velocidad del proceso de adquisición de productos para reabastecer su
inventario.
P á g i n a | 12
1.2 Objetivos
1.2.1 Objetivo general.
Desarrollar una aplicación móvil de abastecimiento de inventarios mediante el uso de Smart
Contracts para la empresa Coninco SRL.
1.2.2 Objetivos específicos.
 Recopilar información del proceso de abastecimiento de inventarios que se realizan en
Coninco SRL, incluyendo las etapas por las que atraviesa y métodos aplicados en cada
registro.
 Definir las actividades del proyecto haciendo uso de SCRUM como metodología ágil de
desarrollo de software.
 Realizar la captura de requerimientos funcionales y no funcionales de la aplicación,
identificando a los usuarios y casos de uso a desarrollar de acuerdo a las expectativas del
problema.
 Diseñar el modelo conceptual de la base de datos que pueda soportar los requisitos del
sistema.
 Realizar los distintos tipos de diseño que dispondrá el sistema de acuerdo a cómo será
desarrollado.
 Desarrollar interfaces de software intuitivas para los usuarios.
 Realizar pruebas con el objetivo de encontrar errores.
1.3 Alcance
En esta aplicación se desarrollarán varias tareas en el registro físico de inventarios dirigidas a
la empresa Coninco SRL.

P á g i n a | 13
1.3.1 Módulo Usuario
Este módulo describe los procesos referentes a la gestión de nuestros empleados dentro del área de
inventarios de la empresa, incluyendo sus cargos y actividades realizadas, así como también el usuario
asignado y el tipo de rol dentro del sistema que manejarán.
1.3.2 Módulo Producto
Este módulo describe el registro y gestión de cada producto que se almacena dentro de la empresa,
para poder visualizar las características, así como también conocer la procedencia y categorías de cada
producto.
1.3.3 Módulo Inventario
En el módulo de inventario, se especificará la forma de registro de los productos dentro de nuestro
almacén para poder clasificarlos de acuerdo a su estado, costo y entre otros, el abastecimiento de los
productos con los proveedores haciendo uso de Smart Contracts, además de una sección para generar
reportes sobre nuestros productos disponibles.
1.4 Fundamentación Teórica
1.4.1 Metodología Ágil
1.4.1.1 Propósito de SCRUM
Un conjunto de principios y valores a tener en cuenta para evitar los problemas de los sistemas
tradicionales de desarrollo de software.
Como contrapartida a las metodologías de gestión de proyectos tradicionales, en donde los métodos de
trabajo son muy formales, y conllevan realizar una gran carga de trabajo de gestión generando una
gran cantidad de documentación, surgen las metodologías ágiles, nuevos sistemas de gestión que se
basan en dar respuestas a los problemas con los que se encuentran las metodologías tradicionales.
Son metodologías centradas en la iteración (repetición del proceso en ciclos breves, con la intención
de alcanzar el objetivo deseado), comunicación y en la reducción de elementos intermedios,

P á g i n a | 14
fomentando la comunicación entre los miembros del equipo. Se reconocen a las personas como el
principal valor para que un proyecto consiga terminarse de forma correcta. Las metodologías ágiles
son más adecuadas cuando el entorno presenta una cierta incertidumbre o es cambiante.
Hoy en día la gestión de procesos y equipos es un valor fundamental para entender una organización
con gran influencia en los resultados del negocio. Muchas empresas manejan cada departamento como
si fueran partes independientes, sin tener en cuenta que una organización es un todo y no sólo la suma
de sus partes, lo que conlleva a errores de planificación, conflictos, retrasos en los proyectos,
sobrecostes que confluyen en la desmotivación de los equipos como consecuencia de una mala
gestión.
Scrum es una metodología ágil, y como tal: Es un modo de desarrollo de carácter adaptable más que
predictivo. Orientado a las personas más que a los procesos. Emplea la estructura de desarrollo ágil:
incremental basada en iteraciones y revisiones.
1.4.1.2 Equipo de SCRUM
 El dueño del producto (Product Owner)
El Product Owner es el encargado de optimizar y maximizar el valor del producto, siendo la
persona encargada de gestionar el flujo de valor del producto a través del Product Backlog.
Adicionalmente, es fundamental su labor como interlocutor con los stakeholders y sponsors del
proyecto, así como su faceta de altavoz de las peticiones y requerimientos de los clientes. Si el Product
Owner también juega el rol de representante de negocio, su trabajo también aportará valor al producto.
Tradicionalmente, se ha entendido la labor del Product Owner como un gestor de requisitos o un
cliente que se encarga de gestionar el Product Backlog, pero es mucho más que eso. No solo tiene la
responsabilidad de mantener el Product Backlog bien estructurado, detallado y priorizado, sino que
además tiene que entender perfectamente cuál es la deriva que se desea para el producto en todo
P á g i n a | 15
momento, debiendo poder explicar y trasmitir a los stakeholders cuál es el valor del producto en el que
están invirtiendo.
 El Equipo e desarrollo (Development Team)
El equipo de desarrollo suele estar formado por entre 3 a 9 profesionales que se encargan de
desarrollar el producto, autoorganizándose y autogestionándose para conseguir entregar un incremento
de software al final del ciclo de desarrollo.
El equipo de desarrollo se encargará de crear un incremento terminado a partir de los elementos del
Product Backlog seleccionados (Sprint Backlog) durante el Sprint Planning.
 El Scrum Master
El Scrum master o facilitador de proyectos es la figura que lidera los equipos en la gestión ágil
de proyectos. Su misión es que los equipos de trabajo alcancen sus objetivos hasta llegar a la fase de
sprint final eliminando cualquier dificultad que puedan encontrar en el camino.
En otras palabras, el Scrum master es el responsable de que se sigan las prácticas y valores descritos
en el modelo Scrum.
1.4.1.3 Ingeniería de Software Asistida por Computadoras
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software
Asistida por Computadora) son diversas aplicaciones informáticas o programas informáticos
destinadas a aumentar el balance en el desarrollo de software reduciendo el costo de las mismas en
términos de tiempo y de dinero.
Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del software en
tareas como el proceso de realizar un diseño del proyecto, cálculo de costos, implementación de parte
del código automáticamente con el diseño dado, compilación automática, documentación o detección
de errores entre otras.

P á g i n a | 16
Con ayuda de la ingeniería asistida por computadora, los profesionales de la ingeniería pueden crear
prototipos virtuales de los productos. La geometría de un producto es inicialmente elaborada en un
software de Computer-Aided Design (CAD). Esta geometría es importada para un sistema CAE. Una
vez dentro de los sistemas, los modelos pasan por diferentes procedimientos: preprocesamiento,
procesamiento y post-procesamiento. Durante la primera etapa, son definidas las características como
materiales, restricciones e interacción con elementos externos, fuerzas aplicadas, temperaturas, entre
otras.
Ventajas
Las herramientas de ingeniera asistida por computadora pueden ser utilizadas por diferentes industrias
como: construcción civil, metalmecánica, turbomáquinas, aeroespacial, automovilística, aeronáutica,
petróleo y gas, naval, off shore, electrónica, entre otros, y proporcionan beneficios en el desarrollo de
productos tales como:
 Mayor eficiencia y calidad, gracias a que permite prever posibles errores y corregirlos antes de
la fase de prototipo y fabricación;
 Reducción de costos, ya que la simulación es más barata que el desarrollo de prototipos;
 Permite realizar cambios en los proyectos rápidamente;
 Disminuye el tiempo empleado en el desarrollo de producto;
 Reduce la cantidad de prototipos de prueba y en ocasiones hasta los elimina;
 Ayuda en la verificación del producto en cuanto a funcionalidad, ensambles y diseño,
permitiendo la revalidación cada vez que sea necesario;
 Aumento de la competitividad.
P á g i n a | 17
1.4.1.4 Ingeniería basada en Componentes
Permite reutilizar piezas de código pre elaborado que permiten realizar diversas tareas,
conllevando a diversos beneficios como las mejoras a la calidad, la reducción del ciclo de desarrollo y
el mayor retorno sobre la inversión.
Al comparar la evolución del ambiente de IT con el crecimiento de las metrópolis actuales, podemos
entender el origen de muchos problemas que se han presentado históricamente en la construcción de
software y vislumbrar las posibles y probables soluciones que nos llevarán hacia la industrialización
del software moderno.
Este proceso de industrialización ha dado ya sus inicios con implementaciones como la
plataforma .net, la cual impulsa la idea de industrializar el software utilizando tecnologías de
componentes. Los avances y mejoras presentados en esta plataforma van mucho más allá de las
implementaciones iniciales como COM y CORBA, convirtiendo a los componentes .net en verdaderas
piezas de ensamblaje, en un estilo muy similar a las líneas de ensamblaje modernas. Asimismo, los
nuevos paradigmas como las Fábricas de Software proveen de los medios para hacer la transición
desde el 'hacer a mano' hacia la fabricación o manufactura de software.
Si hay algo que ha aprendido el ser humano desde tiempos muy antiguos es a reutilizar el
conocimiento existente para sus cada vez más ambiciosas empresas. En efecto, al reutilizar trozos de
experiencias, ideas y artefactos, no solo nos aseguramos de no cometer los mismos errores del pasado,
sino que logramos construir cosas cada vez más grandes y maravillosas, con bases firmes y calidad
incomparable. Este concepto de la reutilización, uno de los primeros que se nos enseñan a quienes
entramos al mundo del desarrollo de software, habremos de utilizarlo desde el mismo instante en que
escribamos nuestra primera línea de código.
Los sistemas de hoy en día son cada vez más complejos, deben ser construidos en tiempo récord y
deben cumplir con los estándares más altos de calidad. Para hacer frente a esto, se concibió y
P á g i n a | 18
perfeccionó lo que hoy conocemos como Ingeniería de Software Basada en Componentes (ISBC), la
cual se centra en el diseño y construcción de sistemas computacionales que utilizan componentes de
software reutilizables. Esta ciencia trabaja bajo la filosofía de "comprar, no construir", una idea que ya
es común en casi todas las industrias existentes, pero relativamente nueva en lo que a la construcción
de software se refiere.
Para este momento, ya muchos conocen las ventajas de este enfoque de desarrollo y, de la misma
forma, muchos se preguntan día a día el por qué son tan pocos los que realmente alcanzan el éxito
siguiendo esta filosofía. En realidad, hasta ahora solo hemos tanteado un poco con las posibilidades
del software basado en componentes, y es justo hora, en la presente década, que la industria del
software despegará y se perfeccionará para estar a la par de cualquier otra industria del medio. Las
analogías que nos han llevado a estudiar a los sistemas comparándolos con las complejas metrópolis
de la actualidad, así como las iniciativas más innovadoras como las Fábricas de Software de
Microsoft, son la clara representación de que estamos a punto de presenciar un nuevo gran cambio en
la forma como pensamos en software.
1.4.1.5 Smart Contracts
Un Smart contracts es un tipo especial de instrucciones que es almacenada en la BlockChain. Y que
además tiene la capacidad de autoejecutar acciones de acuerdo a una serie de parámetros ya
programados. Todo esto de forma inmutable, transparente y completamente segura.
Ethereum, que es uno de los proyectos más famosos en el sector de los Smart contracts. Es una
plataforma de computación distribuida basada en una BlockChain pública como Bitcoin y que además
permite ejecutar contratos inteligentes P2P (entre los nodos, sin servidores centrales) en una máquina
virtual descentralizada llamada Ethereum Virtual Machine (EVM).
Se basa en toda la teoría de Bitcoin en cuanto a estar distribuido, tener su propia criptomoneda,
mineros e incluso su propio BlockChain entre otras cosas, pero, a diferencia de Bitcoin, Ethereum ha
P á g i n a | 19
creado un intérprete de lenguaje de programación mucho más extenso (Turing completo), permitiendo
añadir lógica mucho más compleja dentro del BlockChain. Es decir, se podría asemejar a un
ordenador distribuido, el cual utiliza su criptomoneda (el ether) como la “gasolina” que necesitan el
contrato para que los mineros puedan ejecutarlo. Es decir, ahora con Ethereum los contratos son
programas con muchas más funcionalidades y posibilidades. Aunque para ello, y esto es algo que
mucha gente les critica, han tenido que crear toda una nueva red de cero, renunciando a la red de
Bitcoin (la más potente del mundo). (Bitme2, 2020)
1.5 Propósito del Plan del Proyecto
El propósito del Plan de Desarrollo de Software es proporcionar la información necesaria para
controlar el proyecto, describe durante su elaboración el enfoque de la metodología de desarrollo del
software Scrum. A continuación, listamos los propósitos del Plan de Desarrollo de Software:
1. Definir y establecer el ámbito donde se desarrollará el proyecto.
2. Planificar la gestión de los recursos que se utilizara en el proyecto.
3. Analizar los riesgos y planificar las acciones preventivas a ser aplicadas.
4. Definir los escenarios del “Mejor caso” y “Peor caso”.
5. Proporcionar la guía de desarrollo de software a todo el personal que trabaja en el proyecto.
6. Documentar los procesos que garantizaran la calidad.
7. Establecer las directrices que ayudaran a gestionar los cambios.
Por su parte cada integrante de Grupo de Desarrollo utilizará este documento para:
1. Organizar la agenda y necesidades de recursos (Gerente General).

P á g i n a | 20
2. Realizar el seguimiento al proyecto software (jefe del Departamento de Tecnología de la
Información).
3. Entender lo qué deben hacer, cuándo deben hacerlo y qué otras actividades dependen de
ello (jefe de Área de Desarrollo).
1.6 Métricas en el Software
2 Facto No Incidental Moderado Medio Significativo Esencial Valor

influye
r 0 1 2 3 4 5
1 ¿El Sistema requiere respaldo 3
y recuperación confiables?
2 ¿Se requieren comunicaciones 3
de datos especializadas para
transferir información desde la
aplicación?
3 ¿Existen funciones de 2
procesamiento distribuidas?
4 ¿El desempeño es crucial? 4
5 ¿El sistema correrá en un 5
entorno operativo existente
enormemente utilizado?
6 ¿El sistema requiere entrada 5
de datos en línea?
7 ¿La entrada de datos en línea 1
requiere que la transacción de
entrada se construya sobre
múltiples pantallas u
operaciones?
8 ¿Los ALI se actualizan en 1
línea?
9 ¿Las entradas, salidas, 2
archivos o consultas son?
10 ¿El procesamiento interno es 2
complejo?
11 ¿El código se diseña para ser 3
reutilizable?
12 ¿La conversión y la instalación 2
se incluyen en el diseño?
13 ¿El sistema se diseña para las 1
instalaciones múltiples en
diferentes organizaciones?
14 ¿La aplicación se diseña para 2
facilitar el cambio y su uso por
parte del usuario?
Suma: 36
Factor de Peso
Parámetro de medición Cuenta Simple Medio Complejo Total
P á g i n a | 21
Número de entradas de usuario 4 3 4 6 12

Número de salidas de usuario 3 4 5 7 12
Número de peticiones de usuario 3 3 4 6 9
Número de archivos 6 7 10 15 60
Número de interfaces externas 4 5 7 10 28
Cuenta Total: 121
n
PF = CTA.TOT.∗[0 , 65+0 , 01∗∑ ❑ F i ]
i=1
PF = 121* [0,65 + 0,01 * 36]

PF = 122.21 ≈ 122
1.7 Análisis de Riesgo
SG: Significativo.
CR: Critico.
% PLAN DE AVERSIÓN
PROBA IMPAC
RIESGO
BILIDA TO REDUCCIÓN
REDUCCIÓN IMPACTO
D PROBABILIDAD
- Jerarquía de Programadores.
R1: Integrante del - Firmar un contrato.
- Usar estándares de codificación.
equipo de desarrollo 40 SG - Mejorar ambiente de trabajo.
renuncia al proyecto. - Motivar al equipo de desarrollo.
- Realizar mantenimiento. - Tener accesorios para reemplazar

R2: Fallas del
25 SG - Adquirir buenos productos. el hardware dañado.
Hardware.
-Tener personal de mantenimiento.
- Adquirir un servidor de paga y -Tener la base de datos actualizados
confiable en el teléfono celular
R3: Fallas en la
30 SG
conexión al servidor -La velocidad de internet de subida
del servidor sea óptimo para los
usuarios.
P á g i n a | 22
- Realizar periódicamente copias - Usar diferentes dispositivos de

R4: Perdidas de de seguridad de la información almacenamiento (CD, Pen Drive,
15 CR
Información. - Contar con antivirus actualizados etc.) que sean seguros, de buena
en todos los equipos. calidad, etc.
R5: incumplimiento de - Mantener actualizado la base de - Flexibilidad de adaptación.
expectativas de los 50 CR datos de todas las enfermedades
usuarios que hay en el medio.
- Habilitar una cuenta en la
R6: Desacuerdo entre
plataforma web para la
los especialistas 10 SG
modificación de la base de
humanos
conocimiento
- Capacitar a las personas que - Contratar personas con

R7: Insertar malas
deseen llenar las reglas a la conocimientos avanzados en las
reglas en la base de 40 SG
base de datos enfermedades y las reglas de la
datos
aplicación.
- En el momento de realizar la - Contemplar dentro de la

planificación de tiempos y planificación de tiempo una posible
actividades, se debe considerar un demora asumiendo cualquier tipo de
R8: Mala estimación de
60 SG calendario en el cual contemple eventualidad.
tiempo de desarrollo.
posibles eventualidades con los
integrantes del equipo de
desarrollo
- Realizar estudios para elegir la - Elegir una buena plataforma de
R9: Mala elección de la
mejor plataforma. desarrollo.
plataforma de desarrollo 10 SG
- Tener información actualizada de
del software.
las plataformas de desarrollo.
1.8 Tabla de Recursos
FECHAS COSTO % COSTO

RECUROS CANTIDAD UNITARIO TOTAL
DESDE HASTA ($) DEPRECIACIÓN ($)
HARDWARE
PC 12/10/21 11/01/22 2 700 25 1400
ROUTER 12/10/21 11/01/22 1 300 30 300
SERVIDOR 01/01/22 11/01/22 1 0 0 0
P á g i n a | 23
SOFTWARE
WINDOWS 10 12/10/21 11/01/22 2 99 0 198
FLUTTER 12/10/21 11/01/22 2 0 0 0
MODELO C4 12/10/21 11/01/22 2 0 0 0

META MASK 01/01/22 11/01/22 1 10 0 10
VSCODE 12/10/21 11/01/22 2 0 0 0
PERSONAL
GESTOR 12/10/21 11/01/22 2 1500 3000
ANALISIS Y DISEÑO 12/10/21 11/01/22 2 900 1800
PROGRAMADOR 12/10/21 11/01/22 2 350 700

LOGISTICA
MATERIAL DE
ESCRITORIO 12/10/21 11/01/22 2 25 100 25
MUEBLES 12/10/21 11/01/22 2 450 20 900
LIMPIEZA 12/10/21 11/01/22 1 30 30
REFRIGERIO 12/10/21 11/01/22 2 80 160

INFRAESTRUCTURA
LOCAL 12/10/21 11/01/22 2 240 480
ENERGIA
ELECTRICA 12/10/21 11/01/22 2 75 150
AGUA 12/10/21 11/01/22 2 45 90
INTERNET 12/10/21 11/01/22 2 150 300
9543
P á g i n a | 24
1.9 Organización Interna
La estructura de equipo que utilizaremos para el desarrollo del producto será la de Descentralizado
Democrático (DD), ya que es la más conveniente para el grupo de trabajo.
El equipo constará de 2 personas con cargos compartidos.
1. GESTOR Y ENCARGADO DE CALIDAD
2. ANALISTA Y DISEÑADOR
3. PROGRAMADOR
1.10 Mecanismos de Seguimiento y control
El seguimiento y control de un proyecto se lo realiza para asegurar que el equipo de desarrollo cumple
con el Plan de Proyecto, esto se realiza con el fin de medir costo, tiempo y performance del proyecto.
Entre las tareas a realiza se encuentran:
 Seguir y revisar los resultados y logros del proyecto
 Revisar el Plan de Proyecto para reflejar los resultados obtenidos y ajustar las tareas
restantes en caso de ser necesario.
 Analizar el progreso en la ejecución del Plan.
 Tomar acciones correctivas en caso de desvíos.
 Fijar nuevas metas.
El seguimiento y control se lo pretende realizar de la siguiente manera:
 Realizar reuniones periódicas del estado del proyecto en las que todos los miembros del
equipo presentan un informe de los progresos y de los problemas.

P á g i n a | 25
 Evaluar los resultados de todas las revisiones realizadas a lo largo del proceso de
ingeniería de software.
 Determinar si se han conseguido los hitos formales del proyecto en la fecha programada,
para ello se deben definir primeramente los objetivos que se esperan conseguir al llegar a
cada uno de los hitos.
 Comparar la fecha real de inicio con las previstas para cada tarea del proyecto.
Reuniones informales con los profesionales del software para obtener su valoración subjetiva del
progreso hasta la fecha y los problemas que se avecinan.

P á g i n a | 26
CAPÍTULO II:
MODELOS DE DESARROLLO DE
SOFTWARE
P á g i n a | 27
Capítulo 2: Modelos de Desarrollo de Software
2.1 Modelo de Contexto General
Ilustración 1 Modelo de Contexto General

P á g i n a | 28
2.2 Modelo de Arquitectura
7.2.1 Diseño de la arquitectura lógica
Ilustración 2 Diseño de la Arquitectura Lógica
7.2.2 Diseño de la arquitectura física
Ilustración 3 Diseño de la Arquitectura Física

P á g i n a | 29
2.3 Modelo de Datos
Ilustración 4 Modelo de Datos
2.4 Marco de Trabajo de Desarrollo Scrum
2.4.1 Personas y roles del proyecto
El Product Owner será Sergio Melendez y el Scrum Máster y equipo de desarrollo estará
compuesto será Victor Zambrana.
2.4.2 Sprint Planning Meeting (Reunión de Planeamiento del Sprint)
ID Historia Responsable Tiempo Estimacion Prioridad Estado

Planificar
SP01 reunion de Todo el 1hr 3 Alta Completo
organización equipo
SP02 Documentar el Todo el 4hr 6 Alta Completo

PAPS equipo
P á g i n a | 30
Determinar las
herramientas de
SP03 45min 1 Media Completo
uso en el Todo el
proyecto equipo
Instalar y
preparar las Todo el
SP04 1 hr 2 Media Completo
herramientas de equipo
uso
Implementar Equipo
SP05 4hr 13 Alta Completo
base de datos desarrollo
Refinar
requisitos
Todo el 1hr
SP06 funcionales para 3 Media Completo
equipo 30min
utilizarlos con
los casos de uso
Elaborar una scrum 3hr
SP07 guía sketch del 8 Media Completo
master 30min
producto final
Preparar el Todo el
SP08 entorno y alistar 45min 3 Alta Completo
equipo
vistas en Dart
Planificación del
HU00 alcance y Todo el 1hr
5 Alta Completo
1 funcionalidades equipo 30min
del proyecto
HU00 Diseño de la base Product
2hr 7 Alta Completo
2 de datos Owner
HU00 Elaboración del Todo el
marco de trabajo 2hr 7 Bajo Completo
3 equipo
scrum
Implementación
HU00 de la base de Product
7hr 13 Alta Completo
4 datos en Owner
FireBase
Login y agregar
HU00 los tokens Equipo
4hr 7 Alta Completo
5 necesarios para desarrollo
el ingreso
HU00 Desarrollar el Equipo
6 CU Roles desarrollo
Equipo
HU07 Desarrollar el 6hr 12 Alta Completo
desarrollo
CU Usuario
Desarrollar el Equipo
HU08 6hr 12 Alta Completo
CU Cargos desarrollo
P á g i n a | 31
Desarrollar el Equipo
HU09 6hr 12 Alta Completo
CU Personal desarrollo
HU01 Desarrollar el Equipo
0 CU Almacen desarrollo
Equipo
HU011 Desarrollar el 6hr 12 Alta Completo
CU Seccion desarrollo
HU01 Equipo
Desarrollar el 6hr 12 Alta Completo
2 desarrollo
CU Categoria
HU01 Equipo
3 desarrollo
CU Producto
Desarrollar el
Smart Contract y
HU01 Product
hacer una 3hr 4 Alta Completo
4 Owner
conexión con
MetaMask
HU01 Equipo
5 desarrollo
CU Inventario
HU01 Equipo
6 desarrollo
CU Reportes
HU01 Todo el
3hr 5 Alta Completo
7 Prueba de errores equipo
Desarrollo de la
HU01 Página de la Product
3hr 4 Alta Completo
8 empresa y subir Owner
la aplicación
2.4.2.1 Pila del Sprint (Sprint Backlog) Sprint 0
SPRINT 0 ESFUERZO

Pila del Sprint
20-jun
21-jun
22-jun
26-jun
23-jun
24-jun
25-jun
Codigo Historia Tarea Prioridad Responsable
SP1 Planificar Determinar media Todo el

reunión de correctamente el equipo
P á g i n a | 32
rubro de trabajo
organizació
n Organizar horas de Todo el
media
trabajo equipo
Scrum master
Realizar alcance del
alta y
proyecto
Product owner
Scrum master
Documentar Objetivos generales y
alta y
el PAPS específicos
SP02 Product owner
Scrum master
Buscar antecedentes media y
Product owner
Instalar y
preparar
Todo el
SP03 Herramienta instalar starUML media
equipo
s de
uso
habilitar artefactos Todo el

media
SP04 Determinar scrum equipo
herramienta
s de Preparar máquina para
Todo el
desarrollo el media
equipo
trabajo
Equipo de
SP05 diseñar base de datos alta
desarrollo
normalizar base de Equipo de

Implementa datos
alta
desarrollo
r
base de Equipo de
datos
terminar diseño lógico alta
desarrollo
escribir script de la
Equipo de
base de alta
datos
desarrollo

Scrum master
SP06 Hallar casos de uso alta y
Product owner
Refinar Scrum master

Empaquetar los casos
Requisitos baja y
funcionales
de uso
Product owner
para
utilizarlos Determinar sprints en Scrum master
en los torno a media y
casos de uso los paquetes Product owner
Scrum master
Planificación de sprint alta y
Product owner
Equipo de
SP07 Diseñar el sketch media
elaborar una desarrollo
guía
Equipo de
sketch del Visualizar en figma alta
desarrollo
producto
final conectar botones Equipo de
destino
baja
desarrollo
SP08 Preparar el alta Todo el
entorno y equipo
P á g i n a | 33
instalar laravel en el Todo el

alistar vistas
proyecto
alta
equipo
en Dart
Todo el
alistar el entorno media
equipo
2.4.2.2 Reunión Diaria (Daily Scrum)
Dayly Scrum
Desarrollador Pregunta lunes martes miércoles jueves Viernes sábado Domingo
¿Qué hice Avance
Investigue al estar Logre
ayer para Complete otras
Adelante sobre hice consultas estancado concluir
lograr el las tareas secciones
tareas programación sobre los casos trabaje en el trabajo
Sergio Driss objetivo del designadas del
web paralelo del sprint
Melendez sprint? producto
Martinez,
¿Qué hare Adelantar
Victor Consultar Consulta Igualar
hoy para Iniciar con las Investigar verificar la
Valentín sobre el r sobre el el trabajo
mejorar el anticipación próximas documentation documentación
Zambrana progreso progreso perdido
equipo? tareas
García
¿Tengo algún
impedimento No No No No si si No
?
2.4.2.3 Sprint Review
Detalles del
ID Tarea Terminado Incompleto
problema
Planificar reunión de
SP01 Finalizado NO Ninguno
organización
SP02 Documentar el PAPS Finalizado NO Ninguno
Instalar y preparar las

herramientas de uso
Determinar las herramientas

de uso en el proyecto
SP05 Implementar base de datos Finalizado NO Ninguno

P á g i n a | 34
Refinar requisitos funcionales

SP06 para utilizarlos con los casos Finalizado NO Ninguno
de uso
Elaborar una guía sketch del

producto final
Preparar el entorno y alistar Desconocimiento

SP08 Finalizado NO
vistas en Dart parcial de Flutter
2.4.2.4 Sprint Retrospective
Sprint Retrospective
Nombre Rol ¿Qué hicimos bien?
Sergio Melendez, Nos organizamos muy bien, pudimos alistar e

Equipo Scrum
Victor Zambrana investigar todo lo necesario a tiempo
Nombre Rol ¿Qué debemos dejar de hacer?
Sergio Melendez, Dejar de posponer el desarrollo web e

Equipo Scrum
Victor Zambrana investigación de implementación
Nombre Rol ¿Qué podemos mejorar?
Sergio Melendez, Mejorar la concentración y delegar mejores los

Equipo Scrum
Victor Zambrana tiempos para la producción
2.4.3 Sprint 1
2.4.3.1 Personas y roles del proyecto
P á g i n a | 35
2.4.3.2 Planeación de la Iteración del Sprint (Product Backlog)
27-jun
28-jun
29-jun
30-jun
01-jul
02-jul
03-jul
SPRINT 1
Pila del sprint Esfuerzo

Código Historia Responsable
HU001 Planificación del Todo el
alcance y equipo
funcionalidades del
proyecto
HU002 Diseño de la base de Equipo
datos desarrollo
HU003 Elaboración del Todo el
marco de trabajo equipo
Scrum
HU004 Implementación de Todo el
la Base de Datos en equipo
Firebase
HU005 Login y agregar los Equipo
tokens necesarios desarrollo
para el ingreso
HU006 Desarrollar el CU Equipo
Roles desarrollo
Usuario desarrollo
Cargos desarrollo
Personal desarrollo
2.4.3.3 Historias de Usuario
Historia De Usuario
Numero: HU5 Usuario: Administrador y Empleado
Nombre de Historia: Mostrar inicio

P á g i n a | 36
Prioridad en negocio: Media Riesgo en desarrollo: Media
Descripción: Esta funcionalidad permitirá poder ver un panel de inicio agradable a la vista y
que cumpla la función de representación de la pagina
Condición de Satisfacción:
*Se podrá navegar fácilmente y muestra una interfaz amigable.
*Funciona como carta de presentación de la página.
2.4.3.4 Sprint Planning Meeting
Estimación
ID
Titulo Participantes (Hrs) Puntos
Planificación del alcance y

HU001 Todo el equipo 1hr 30min 5
funcionalidades del proyecto
HU002 Diseño de la base de datos Product Owner 2hr 7
Elaboración del marco de

HU003 Todo el equipo 2hr 7
trabajo scrum
Implementación de la base de
datos en Firebase
Login y agregar los tokens

HU005 Equipo desarrollo 4hr 6
necesarios para el ingreso
HU006 Desarrollar CU Roles Equipo desarrollo 6hr 8
HU007 Desarrollar CU Usuario Equipo desarrollo 6hr 8
Desarrollar CU Cargos
HU008 Equipo desarrollo 6hr 8
HU009 Desarrollar CU Personal Equipo desarrollo 6hr 8

P á g i n a | 37
2.4.3.5 Daily Scrum
Dayly Scrum
Pregunta lunes martes miércoles jueves viernes sábado domingo
¿Qué
Comple
hice ayer
teamos Investiga hicimos al estar Avanzamos Logramos
para Adelanta
las mos sobre consultas estancado otras concluir el
lograr el mos
tareas programac sobre los trabajamos secciones del trabajo del
objetivo tareas
designa ión web casos en paralelo producto sprint
del
das
sprint?
¿Qué
hare hoy Iniciar Adelanta verificar
Investigar Consultar Consultar
para con r las la Igualar el
document sobre el sobre el
mejorar anticipa próximas documen trabajo perdido
ación progreso progreso
el ción tareas tación
equipo?
¿Tengo
algún
No No No No si si No
impedim
ento?
Sergio Melendez, Avanzar con facilidad la documentación debido a

Equipo Scrum
Victor Zambrana plantillas preparadas
Sergio Melendez, Dejar de posponer el desarrollo móvil e

Equipo Scrum
Victor Zambrana investigación de implementación
Sergio Melendez, Equipo Scrum Investigar mejor y tener más conocimiento de la

P á g i n a | 38
Victor Zambrana programación móvil
2.4.3.7 BurnDown
Dia Fecha Estimacion Avance real Progrecion
Inicio 43 43
lunes 27-jun 37 7 36
martes 28-jun 31 7 29
miércoles 29-jun 25 5 24
jueves 30-jun 18 6 18
viernes 01-jul 12 3 15
sábado 02-jul 6 8 7
domingo 03-jul 0 7 0
Sprint 1
50
45
40
35
30
25
20
15
10
5
0
Estimacion Progrecion
Ilustración 5 Sprint 1
Detalles del
problema
HU001 Planificación del alcance y Finalizado NO Ninguno

P á g i n a | 39
funcionalidades del proyecto
HU002 Diseño de la base de datos Finalizado NO Ninguno
Elaboración del marco de

HU003 Finalizado NO Ninguno
trabajo scrum
Implementación de la base
de datos en Firebase
Login y agregar los tokens

necesarios para el ingreso
HU006 Desarrollar el CU Roles Finalizado NO Ninguno
HU007 Desarrollar el CU Usuario Finalizado NO Ninguno
HU008 Desarrollar el CU Cargos Finalizado NO Ninguno
HU009 Desarrollar el CU Personal Finalizado NO Ninguno
2.4.4 Sprint 2
2.4.4.1 Personas y roles del proyecto
2.4.4.2 Planeación de la Iteración del Sprint (Product Backlog)

27-jun
28-jun
29-jun
30-jun
01-jul
02-jul
03-jul
SPRINT 1
Pila del sprint Esfuerzo

Código Historia Responsable
HU010 Desarrollar el CU Todo el
Almacén equipo
Sección desarrollo
Categoría equipo
P á g i n a | 40

Producto equipo
HU014 Desarrollar el Smart Equipo
Contract y hacer una desarrollo
conexión con
MetaMask
Inventario desarrollo
Reportes desarrollo
HU017 Prueba de errores Equipo
desarrollo
HU018 Desarrollar de la Equipo
página de la empresa desarrollo
y subir la aplicación
2.4.4.3 Historias de Usuario
Historia De Usuario
Numero: HU10 Usuario: Administrador
Nombre de Historia: Gestionar CU Almacén
Prioridad en negocio: Alta Riesgo en desarrollo: Media
Descripción: Esta funcionalidad permitirá gestionar los datos sobre nuestros almacenes dentro
de la empresa
Condición de Satisfacción:
*Se podrá registrar, editar o eliminar un almacén.
*Permite a la empresa manejar el alojamiento de las secciones dentro de los akmacenes.
2.4.4.4 Sprint Planning Meeting
ID Titulo Participantes Estimación Puntos

P á g i n a | 41
(Hrs)
HU010 Desarrollar el CU Almacen Equipo desarrollo 6hr 8
HU011 Desarrollar el CU Seccion Equipo desarrollo 6hr 8
HU012 Desarrollar el CU Categoria Equipo desarrollo 6hr 8
HU013 Desarrollar el CU Producto Equipo desarrollo 6hr 8
Desarrollar el Smart Contract

HU014 y hacer una conexión con Product Owner 3hr 6
MetaMask
HU015 Desarrollar CU Inventario Equipo desarrollo 6hr 8
HU016 Desarrollar CU Reportes Equipo desarrollo 6hr 8
Prueba de errores
Desarrollo de la página de la
HU018 Product Owner 3hr 4
empresa y subir la aplicación
2.4.4.5 Daily Scrum
Dayly Scrum
Pregunta lunes martes miércoles jueves viernes sábado domingo
¿Qué
Comple
hice ayer
teamos Realizamos Logramos
para Adelanta Adelanta
las Adelanta Adelantamo las pruebas concluir el
lograr el mos mos
tareas mos tareas s tareas correspondie trabajo del
objetivo tareas tareas
designa ntes sprint
del
das
sprint?
¿Qué Iniciar Adelanta Adelantar Adelanta Adelantar Adelantar las Igualar el
hare hoy con r las las r las las próximas trabajo perdido
para anticipa próximas próximas próximas próximas tareas
mejorar ción tareas tareas tareas tareas
el
P á g i n a | 42
equipo?
¿Tengo
algún
No No No No No No No
impedim
ento?
Sergio Melendez,
Equipo Scrum Avanzar con facilidad el desarrollo del Software
Victor Zambrana
Sergio Melendez,
Equipo Scrum Perder demasiado tiempo con otras actividades
Victor Zambrana
Sergio Melendez,
Equipo Scrum Agilizar nuestros métodos de desarrollo
Victor Zambrana
2.4.4.7 BurnDown
Dia Fecha Estimacion Avance real Progrecion
Inicio 43 43
lunes 04-jul 37 7 36
martes 05-jul 31 7 29
miércoles 06-jul 25 5 24
jueves 07-jul 18 6 18
viernes 08-jul 12 3 15
sábado 09-jul 6 8 7
P á g i n a | 43
domingo 10-jul 0 7 0
Sprint 1
50
45
40
35
30
25
20
15
10
5
0
Estimacion Progrecion
Ilustración 6 Sprint 2
Detalles del
problema
HU010 Desarrollar el CU Almacén Finalizado NO Ninguno
HU011 Desarrollar el CU Sección Finalizado NO Ninguno
Desarrollar el CU
Categoría
HU013 Desarrollar el CU Producto Finalizado NO Ninguno
Desarrollar el Smart
HU014 Contract y hacer una Finalizado NO Ninguno
conexión con MetaMask
HU015 Desarrollar el CU Inventario Finalizado NO Ninguno
HU016 Desarrollar el CU Reportes Finalizado NO Ninguno
HU017 Prueba de errores Finalizado NO Ninguno

P á g i n a | 44
Desarrollo de la página de la
HU018 empresa y subir la Finalizado NO Ninguno
aplicación
CAPÍTULO III:
MANUAL DE CALIDAD SQAP
P á g i n a | 45
Capítulo 3: Manual de Calidad
3.1 Introducción a la guía del SQA
3.1.1 Introducción
El software es inmaterial y cada vez está más presente en nuestra actividad laboral y en los objetos que
nos rodean y que usamos. La calidad del producto software es una preocupación cada vez mayor en el
ámbito informático y cuyos resultados inmediatos se aprecian en todas las actividades en donde se
utilicen computadoras.
Las necesidades de calidad del usuario sobre el software, contribuyen a especificar los
requerimientos de calidad externa y estos a su vez los requerimientos de calidad interna. El
cumplimiento de los requerimientos de calidad interna, externa y en uso se deben de comprobar en un
proceso que permita evaluar la calidad a través de las métricas. Con este enfoque de tres niveles se
intenta cubrir las perspectivas del usuario, desarrollador y el producto mismo. El desarrollo de
productos software no está ausente de ofrecer calidad. Dicho nivel de calidad, incluido en los
productos, considera muchas actividades dentro del desarrollo de los proyectos software, la gestión de
la calidad dentro de este tipo de proyectos puede estandarizarse dentro de la organización y
certificarse a la comunidad de clientes. La calidad en el desarrollo de software es alcanzable si la
organización elige su norma de referencia y define y desarrolla su Plan de Calidad.
La Calidad cuesta, pero resulta más costoso el no tenerla en un ambiente competitivo como el
actual. La calidad es el rasgo diferenciador entre las organizaciones capaces de destacarse en el
mercado y aquellas que simplemente sobreviven o desaparecen.
Necesidades de Calidad en
Calidad del uso
Usuario Uso y
retroalimentación
Contribuye a
especificar Indica
de Calidad externa P á g i n a | 46
externa Validación
Contribuye a
especificar Indica
Requerimientos de Calidad
Calidad interna Interna
Verificación
3.1.2 Objetivo General del plan SQA
El desarrollo de un plan de aseguramiento de la calidad de software para la empresa.
3.1.2.1 Objetivos Específicos del Plan SQA
Como empresa, se tienen los siguientes objetivos:
 Definir los requerimientos de calidad a ser verificados.
 Indicar los roles y responsabilidades de cada integrante del equipo y director del plan SQA.
 Indicar las partes del ciclo vida cubierto por el plan SQA, así como las líneas de trabajo que
serán contempladas en el mismo.
 Describir las tareas de calidad a realizar.
 Especificar los documentos involucrados en el desarrollo del plan.
3.1.3 Misión
La misión de la empresa CONINCO SRL es ser un equipo dinámico y responsable, comprometidos en
brindar servicios de construcción que superen las expectativas de nuestros clientes.

P á g i n a | 47
3.1.4 Visión
Nuestra visión es continuar siendo una empresa líder a nivel nacional en desarrollo y construcción y a
la vez expandirse a través de alianzas corporativas, siempre actualizándonos de acuerdo a los
permanentes retos tecnológicos.
3.1.5 Políticas de Calidad
A través del compromiso para innovar y mantener la vanguardia en los proyectos de CONINCO
S.R.L. es que se garantiza cumplir las políticas de calidad en la empresa.
Nos comprometemos a cumplir con lo requisitos del cliente y partes interesadas, así como con los
requisitos legales, reglamentarios y administrativos, propios de la organización y a mejorar
continuamente la eficacia del Sistema de Gestión de la Calidad, a través del desarrollo de nuestros
objetivos estratégicos, con personal competente.
Objetivos para lograr nuestras políticas:
 Con base en las directrices determinadas en la Política de Calidad, se establecieron los
siguientes objetivos generales, para dar cumplimiento a la misma:
 Cumplir con los requisitos del cliente y partes interesadas, así como los legales, reglamentarios
y administrativos.
 Mejora continua de la eficacia del Sistema de Gestión de la Calidad.
3.1.6 Eslogan
“Haciendo posible tus ideas”.

P á g i n a | 48
Ilustración 8 Eslogan de la Empresa
3.2 Plan de aseguramiento de calidad del Software
3.2.1 Propósito
El propósito de este plan es especificar las actividades que se realizarán para asegurar la calidad del
software a construir. En él se detalla el producto que se va a revisar y los estándares, normas o
métodos a aplicar, los métodos y procedimientos que se utilizarán para revisar que la elaboración del
producto se realice como lo establece el modelo de ciclo de vida del proyecto, y procedimientos para
informar a los responsables del producto los defectos encontrados y realizar un seguimiento de dichos
defectos hasta su corrección.
3.2.2 Objetivo
Definir un conjunto de normas y actividades con el fin de asegurar la calidad en el desarrollo de
software.
3.2.3 Descripción
Calidad del software es el cumplimiento con los requisitos explícitamente establecidos y
documentados, la concordancia con los estándares de desarrollo explícitamente documentados y la
agregación de requisitos implícitos que se espera de todo producto hecho por profesionales (IEEE).
P á g i n a | 49
A través de la implantación del SQAP se pretende cumplir con los elementos de calidad de
software, los cuales son:
 Correcto
 Eficiente
 Fiable
 Facilidad de uso
 Facilidad de mantenimiento
 Seguridad e integridad
 Portabilidad
Para obtener productos de software con gran competitividad en el mercado, y poder satisfacer
plenamente los requerimientos de los clientes.
3.2.4 Alcance
El SQAP cubre todos los ciclos basándonos en la metodología Ágil SCRUM.
3.2.5 Documentos de Referencia
 IEEE STD 730-1998, IEEE Standard for Software Quality Assurance Plans.
 IEEE STD 730.1-1995, IEEE Guide for Software Quality Assurance Planning.
 IS-1(2001) – Proyecto de Ingeniería de Software
 IS-2 (2001) - Modelo de Calidad
 ANSI / IEEE – STD 830 Guide for Software Requirements Specifications
 ANSI / IEEE – STD 1016 Recommended Practice for Software Design Descriptions
 ANSI / IEEE – STD 1008 Standard for Software Unit Testing
 ANSI / IEEE – STD 1063 Standard for Software User Documentation
 ANSI / IEEE – STD 1028 Standard for Software Reviews and Audits
P á g i n a | 50
 Documento de Actividades de Gestión de Calidad – A. Delgado & B. Pérez 2000.
3.3 Gestión
3.3.1 Organización del cliente
Ilustración 9 Organización del cliente
3.3.2 Organización del SQA
Es la organización que discute las normas y sugerencias generadas por el consultor, para luego
aceptarlas y liberar versiones sucesivas del SQAP para el desarrollo e implementación del software,
esta organización se obtiene de las tres organizaciones anteriores.
La especificación de la organización de la SQA es la siguiente:
Lista de personas:
 Gerente Administrativo
 Jefe de Departamento de Informática

P á g i n a | 51
 Director General
 Experto en Proyectos
 Experto en Ciencias de la Computación
 Director de Equipo de Desarrollo
 Jefe de Desarrollo
3.3.3 Tareas
Para este curso las actividades de SQA definidas en el modelo de proceso son:
Actividad Entregable Asociado

Elaboración del Plan de SQA Plan de SQA
Identificar propiedades de Calidad Plan de SQA
Evaluación de la calidad de los productos Informe de revisión de SQA
Revisar el ajuste al proceso Informe de revisión de SQA
Realizar Revisión Técnica Formal Informe de Revisión Técnica Formal
Evaluar y ajustar el Plan de SQA Documento de Evaluación y Ajustes al Plan de
SQA
Evaluación final de SQA Informe final de SQA
Revisar la entrega semanal Entrega semanal de SQA
Se deben identificar las actividades del proceso que son previas a las actividades de SQA, indicando la
secuencia de las mismas y los puntos clave en el proceso en los que serán realizadas estas actividades.
P á g i n a | 52
Ilustración 10 Secuencia de tareas
3.4 Documentación
3.4.1 Especificación de requisitos de Software
Esta documentación es elaborada por el desarrollador, y se basa en el estándar ANSI /
IEEE-Std 830 “Guía para especificaciones de requerimientos de software” (SRS).
La SRS deberá describir claramente y de forma precisa cada uno de los requerimientos del
Software, tal como: funciones, rendimiento, restricciones de diseño y atributos.
MODELO A USAR PARA EL CONTENIDO DEL SRS
1. INTRODUCION
1.1 Objetivo
1.2 Alcance
1.3 Definiciones, acrónimos y abreviaciones
1.4 Referencias
P á g i n a | 53
1.5 Revisión
2. DESCRIPCION GENERAL
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Características de los usuarios
2.4 Restricciones generales
2.5 Asunciones y dependencias
3. ESPECIFICACION DE REQUERIMIENTOS
3.1 Requerimiento Funcional
3.1.1. Introducción
3.1.2. Entradas
3.1.3. Procesos
3.1.4. Salidas
3.1.5. Interfaces externas
3.1.5.1. Interfaces del usuario
3.1.5.2. Interfaces del hardware
3.1.5.3. Interfaces del software
3.1.6 Requerimientos de rendimiento
3.1.7 Representación del diseño
3.1.8 Cumplimientos con estándares
3.1.9 Limitaciones del hardware
3.1.10 Atributos
3.1.10.1. Disponibilidad
3.1.10.2. Seguridad
3.1.10.3. Mantenibilidad
3.1.10.4. Transferencia / Conversión
3.1.10.5 Prevenciones
3.1.11 Otros requerimientos
3.1.11.1. Base de datos
3.1.11.2. Operaciones
3.1.11.3. Adaptaciones
APENDICES
P á g i n a | 54
INDICE
ANEXOS
Se definirá en el punto 3. ESPECIFICACION DE REQUERIMIENTOS cada uno de los
requerimientos funcionales del proyecto.
3.4.2 Descripción del Diseño del Software
La generación y documentación de la descripción del diseño de Software se basa en el estándar

ANSI / IEEE – STD 1016 “RECOMMENDED PRACTICE FOR SOFTWARE DESCRIPTIONS”
VISTA DE ALCANCE ATRIBUTOS EJEMPLOS DE

DISEÑO DE ENTIDAD REPRESENTACIONES
Descripción de Partición del sistema Identificación, Diagrama de

descomposición dentro de entidades tipo, objetivo, descomposición, jerarquía
de diseño. función, y lenguaje natural.
subordinación.
Descripción de Descripción de las Identificación, Diagrama de estructura.

dependencia relaciones entre tipo, objetivo,
entidades y recursos dependencias,
del sistema. recursos.
Descripción de Lista de cada Identificación, Tablas de parámetros.

interfaces interfaz de función,
diseñador, interfaces.
programador, o
pruebas necesarias
para conocer el uso
de la entidad de
diseño que
componen el
Descripción de sistema. Identificación, Diagrama de flujos.
detalle procesamiento,
Descripción de los datos.
detalles de diseño
internos en una
entidad.
P á g i n a | 55
MODELO A USAR PARA EL CONTENIDO DEL SDD
1. INTRODUCION
Objetivo
Alcance
Definiciones, acrónimos y abreviaciones
2. REFERENCIAS
3. DESCRIPCION DE DESCOMPOSICION
3.1. Descomposición de módulo
3.1.1. Descripción del módulo 1
3.1.n. Descripción del módulo n
3.2. Descomposición de procesos concurrentes
3.2.1. Descripción del proceso 1
3.2.n. Descripción del proceso n
3.3. Descomposición de datos
3.3.1. Descripción de la entidad de datos 1
3.3.2. Descripción de la entidad de datos 2
3.3.n. Descripción de la entidad de datos n
4. DESCRIPCION DE DEPENDENCIA
4.1 Dependencia entre módulos
4.2 Dependencia entre procesos
4.3 Dependencia entre datos
5. DESCRIPCION DE INTERFACES
5.1 Interfaces de módulo
5.1.n. Descripción del módulo n
5.2 Interfaces de procesos
5.2.n. Descripción del proceso n
P á g i n a | 56
6. DISEÑO DETALLADO
6.1. Diseño detallado del módulo

6.1.1. Detalle del módulo 1
6.1.2. Detalle del módulo 2
6.1.n. Detalle del módulo n
6.2. Diseño detallado de datos
6.2.1. Detalle de entidad de datos 1
6.2.2. Detalle de entidad de datos 2
6.2.n. Detalle de entidad de datos n
APENDICES
INDICE
ANEXOS
3.4.3 Plan de Verificación y validación
La generación y documentación de la descripción del Plan de Verificación y Validación (SWP) es la
siguiente:
MODELO A USAR PARA EL CONTENIDO DEL SWP
1. OBJETIVO
2. ALCANCE
3. DEFINICIONES, ACRONIMOS Y ABREVIACIONES
4. ORGANIZACIÓN RESPONSABLES
5. CICLO DE VIDA DE VERIFICACION Y VALIDACION
APENDICE
INDICE
La organización responsable por las tareas de verificación y validación del software es la organización
de SQA comandada por la organización del consultor, la cual interactúa con la organización de
desarrollo para alcanzar los objetivos del plan. En casos necesarios de conflictos extremos entre el
consultor y el desarrollador se recurrirá al cliente.
P á g i n a | 57
3.4.3.1 Ciclo de vida de verificación y validación
El plan se basa en el siguiente ciclo de vida del software:
Tabla Tareas, entradas y salidas de V&V (Fase 1)
1 FASE DE CONCEPTO V&V
TAREAS MÍNIMAS DE V&V ENTRADAS SALIDAS

REQUERIDAS REQUERIDAS
Evaluación de concepto de documentación Concepto de Reporte de tareas

Evaluar el concepto de documentación para documentación: Reporte de
determinar si el concepto propuesto satisface las Planificación del anomalías
necesidades del usuario y el objetivo del proyecto. proyecto, Memo de
Identificar las restricciones principales de iniciación del proyecto
interfaces del sistema y limitaciones de objetivos
propuestos. Fijar credibilidad de cada elemento de
software
Tabla Tareas, entradas y salidas de V&V (Fase 2)
2 FASE DE DISEÑO V&V

TAREAS MÍNIMAS DE V&V ENTRADAS SALIDAS
REQUERIDAS REQUERIDAS
Análisis de seguimiento a los requerimientos de Concepto de Reporte de tareas.

software. documentación SRS. Reporte de
Seguir los requerimientos SRS hacia los Documentación de anomalías.
requerimientos del sistema dentro del concepto de requerimientos de
documentación. Analizar identificando relaciones interfaces.
para correcciones, consistencia, completitud y
optimización.
P á g i n a | 58
Evaluación de requerimientos de software. Concepto de Reporte de tareas.

Evaluar los requerimientos SRS para: precisión, documentación SRS. Reporte de
cumplimiento, confiabilidad, y capacidad de ser Documentación de anomalías.
probado. Fijar la credibilidad de requerimientos requerimientos de
para identificar rendimiento o área críticas de interfaces.
software.
Concepto de Reporte de tareas.

documentación SRS. Reporte de
Documentación de anomalías.
requerimientos de
interfaces.
Concepto de Plan de pruebas del

documentación SRS. sistema.
Documentación de Reporte de
requerimientos de anomalías.
interfaces.
Documentación de
usuario.
Concepto de Plan de pruebas de

documentación SRS. aceptación.
Documentación de Reporte de
requerimientos de anomalías.
interfaces.
Documentación de
usuario.
3.4.4 Informe de verificación y validación
El formato para la documentación de los resultados de la implementación del plan de verificación y
validación del software (SWR) es la siguiente:
3.4.4.1 Reporte sumario de Fase V & V
REPORTE SUMARIO DE FASE V&V Pág.
FASE:
…......
# De Reporte: Fecha: / /
P á g i n a | 59
Lugar: Hora:
a) Descripción de las tareas de V&V realizadas:
b) Sumario de resultados de tareas:
c) Sumario de anomalías y resolución:
d) Evaluación de calidad del software:
e) Recomendaciones:
Equipo de Trabajo:
Nombre: Firma
3.4.4.2 Reporte de Anomalías
REPORTE DE ANOMALIAS Pág.
FASE:
…......
Lugar:
Hora:
P á g i n a | 60
a) Descripción y ubicación:
b) Impacto:
c) Causa:
a) Critibilidad:
b) Recomendaciones:
Equipo de Trabajo:
Nombre: Firma
3.4.4.3 Reporte final de V & V
REPORTE FINAL DE V&V Pág.
FASE: …......
Lugar: Hora:
P á g i n a | 61
a) Resumen de todas las tareas V&V, durante el ciclo de vida del software:
b) Resumen de resultados de tareas:
c) Resumen de anomalías, resolución:
a) Evaluación total de la calidad del software:
b) Recomendaciones:
Equipo de Trabajo:
Nombre: Firma
3.4.5 Documentación del Usuario (UD)
Esta descripción de documentación de usuario (UD) se basa en el estándar ANSI / IEEE – STD 1036
“STANDARD FOR SOFTWARE USER DOCUMENTATION”.

P á g i n a | 62
La información especificada debe ser incluida en la documentación del usuario, esta documentación
de usuario comprenderá de un conjunto. En cada documento se debe tomar en cuenta y describir los
siguientes puntos.
Los documentos de usuario serán presentados en dos modos: instruccional y de referencia.
Los usuarios del software utilizarán los documentos ya sea para aprender acerca del software (modo
instruccional) o para refrescar su memoria acerca del software (modo de referencia).
Modo Instruccional
Un modo instruccional de documento debe:
 Proveer el ambiente y la información necesaria para entender el sistema.
 Proveer la información necesaria para aprender lo que puede hacer con el software y como lo
puede usar.
 Proveer ejemplos para reforzar el proceso de aprendizaje.
Modo de Referencia
Un documento de modo de referencia debe:
 Organizar y proveer información necesaria.
 Facilitar accesos aleatorios a la información.
Los documentos de modo de referencia que debe ser incluidos son:
a) Manual de comandos.
b) Manual de mensajes de error.
c) Manual de llamadas de programas.
d) Guía de referencia rápida.
e) Manual de Herramientas del software.

P á g i n a | 63
f) Manual de utilitarios.
MODELO A USAR PARA EL CONTENIDO DEL UD
1. TITULO DE LA PAGINA
2. RESTRICCIONES
3. GARANTIAS Y OBLIGACIONES CONTRACTUALES
4. TABLA DE CONTENIDO
5. LISTA DE ILUSTRACIONES
6. INTRODUCCION
Descripción de audiencia
Declaración de aplicación
Declaración de objetivos
6.4 Descripción del uso de documentos
6.5 Documentos relacionados
6.6 Convenciones
6.6.1 Símbolos
6.6.2 Convenciones de estilo
6.6.3 Convenciones de sintaxis de comandos
6.7 Instrucciones de reportes de problemas
7. CUERPO DEL DOCUMENTO
7.1. Cuerpo del documento en modo instruccional
7.1.1 Alcance
7.1.2 Materiales
7.1.3 Preparaciones
7.1.4 Precauciones y prevenciones
7.1.5 Métodos
7.1.6 Información relacionada
7.2. Cuerpo del documento en modo de referencia
7.2.1 Objetivo
7.2.2 Materiales
7.2.3 Preparaciones
7.2.4 Entradas
7.2.5 Precauciones y prevenciones
P á g i n a | 64
7.2.6 Invocación
7.2.7 Operaciones de suspensión
7.2.8 Operaciones de terminación
7.2.9 Salidas
7.2.10 Condiciones de error
7.2.11 Información relacionada
8. MENSAJES DE ERROR, CONOCIMIENTO DE PROBLEMAS,
RECUPERACION DE ERROR
9. ANEXOS
10. BIBLIOGRAFIA
11. GLOSARIO
12. INDICE
3.5 Estándares, prácticas y convenciones
3.5.1 Estándar de codificación
La codificación del software móvil se realizará usando Flutter.
Las normas de codificación se definen de la siguiente forma:
 El software debe ser subdividido en módulos independientes, de acuerdo al diseño establecido.
 La documentación de un programa debe tener el siguiente formato:
o Nombre del programa

Objetivo
o Nombre de las entradas:
Base de Datos
Archivos
Registros
Formatos de pantalla
o Nombre de las salidas:
Base de Datos
Archivos
Registros
P á g i n a | 65
Formatos de pantalla
Reportes
o Nombre de los archivos de actualización:
Base de Datos
Archivos
Registros
o Nombre del autor
Fecha de creación
o Historial de actualizaciones
Versión
Fecha de cambio
Objetivo de cambio
 Cada módulo debe explicar sus funciones

 La declaración de cualquier variable debe estar comentada, explicando su función.
 Debe existir una sola instrucción por cada línea de código.
 Cada función debe de estar debidamente documentada, explicar la funcionalidad, la función de
cada parámetro.
 Cada mensaje de error o excepciones deben de indicar el lugar donde se originó y la función o
procedimiento en el cual se produjo.
 Para asignar nombres a las variables debe de realizarse de la siguiente forma:
x Empleado
x Producto
x Inventario
Donde x = indica el tipo de dato, puede representar: enteros, reales, cadenas, etc.
 Los nombres de las funciones deben de indicar su funcionalidad.

 Cada clase implementada debe de estar comentada de la siguiente forma:
Nombre
Fecha y hora de creación
Autor
Nombre del módulo al que pertenece
Funcionalidad
P á g i n a | 66
3.5.2 Estándar de comentarios
 Un comentario debe explicar porque se realiza alguna acción.

 Los comentarios dentro de un módulo deben estar separados del código.
 Utilizar comentarios de más de una línea para realizar descripciones, y comentarios de una
línea para realizar especificaciones.
3.5.3 Responsables de verificar el cumplimiento
Los responsables de realizar la verificación del cumplimiento con los estándares definidos son:
 El jefe del equipo de desarrollo.
 La organización del SQA.
3.6 Revisiones
Los responsables de estas revisiones es la organización del SQA, con la participación de todo
elemento de la organización que tengan que ver con los requerimientos, tales como: los diseñadores
del software, agentes de pruebas.
Las revisiones y auditorias de los resultados del desarrollo se realizan a medida que se terminan cada
una de las fases del ciclo de vida de desarrollo de software, con el fin de:
 Conocer el progreso alcanzado en el desarrollo.

 Evaluar el ajuste a los requerimientos del sistema.
 Evaluar la eficiencia en el trabajo.
Se deben llevar a cabo, al menos, las siguientes revisiones y auditorias:
3.6.1 Revisiones y auditorías
3.6.1.1 Revisión de los requisitos del Software (SRR)
La SRR se genera para:
 Evaluar las especificaciones de requerimientos del software (SRS).

 Asegurar que los requerimientos establecidos en la SRS, sean los correctos y estén
completos.
 Garantizar la calidad, viabilidad e integridad de los requerimientos establecidos.
P á g i n a | 67
Los requerimientos de revisiones de SRS en la SRR son los siguientes:
a) Fiable
b) Completo
c) Depurable
d) Modificable
e) Consistente
f) Libre de ambigüedades
g) Utilizable durante la fase de operación y mantenimiento.
h) Inspeccionar que la relación entre los requerimientos y sus derivados sea la adecuada.
3.6.1.2 Revisión del Diseño Preliminar (PDR)
La PDR es realizada para evaluar la suficiencia técnica del SDD preliminar, antes de comenzar con el
diseño detallado, define los siguientes puntos:
 Evaluar el progreso, consistencia y suficiencia técnica del alcance de diseño con los
requerimientos funcionales de la SRS.
 Verificar la existencia y compatibilidad de las interfaces entre el software, el hardware
y los usuarios finales.
 Determinar un diseño de software que cumpla con los requerimientos.
Para la PDR se toman como requerimientos de revisiones los siguientes puntos:
 Revisar que se detallen todas las interfaces con otro software, sistemas de
comunicación, etc. Para una adecuada identificación de interfaces y de un diseño
óptimo.
 Revisar que exista un análisis del diseño para verificar la compatibilidad con los
requerimientos críticos.
 Revisar que se establece los requerimientos del factor humano.
3.6.1.3 Revisión del Diseño Crítico (CDR)
La CDR es generada para determinar la aceptabilidad de cómo la SDD cumple con la SRS. Evalúa la
suficiencia técnica, integridad del diseño detallado del software, antes de comenzar a codificar para
establecer que el diseño detallado satisface los requerimientos de la SRS.
Para la CDR se toman como requerimientos de revisión los siguientes puntos:

P á g i n a | 68
 Evaluar la compatibilidad del diseño detallado con la SRS.

 Examinar la representación de datos en forma de diagramas lógicos, algoritmos,
almacenamiento y representación de datos.
 Determinar la compatibilidad e integridad de requerimientos de interfaces.
 Establecer que todas las interfaces internas y externas incluyendo interacciones con la
base de datos sean expresadas.
3.6.1.4 Revisión del Plan de Verificación y validación
La SVVPR es generado para la evaluación de:
 Los métodos de Verificación y Validación definidos en el SVVP.

 El cumplimiento durante el desarrollo del software con el SVVP.
Se realizan revisiones incrementales para asegurar que los métodos de verificación y validación del
software sean los adecuados para los datos del software que se está desarrollando.
Se toman como criterios de requerimientos de la SVVPR los siguientes puntos:
 Reportes para una adecuada documentación de resultados de todas las revisiones,

verificaciones y pruebas basadas en los requerimientos listados en el SVVP.
 Descripciones adecuadas de la configuración del software, para ser examinado,
incluyendo pruebas de soporte de software y hardware.
 Planes de pruebas y diseño de pruebas para asegurar que todos los requerimientos son
examinados.
 Procedimientos y situaciones de pruebas para asegurar que las entradas sean las
adecuadas para el software.
 Programación de pruebas identificando que pruebas serán realizadas, cuando y por
quien van a ser realizadas.
3.6.1.5 Auditoría Funcional
Esta verificación es realizada antes de la entrega del software, para verificar que todos los
requerimientos especificados en la SRS fueron alcanzados.
La verificación funcional compara el código con los requerimientos documentados del software, como
se estableció en SRS. Su propósito es asegurar que el código hace todo y solo lo que se indica en la
documentación establecida por la SRS.
P á g i n a | 69
Se definen los siguientes puntos:
 Nomenclatura
 Número de identificación de la especificación
 Número de ítem de configuración
 La especificación de requerimientos de software
 Copia de código objeto
 Listado actualizado de ítems de configuración especificados
 El reporte de verificación y validación del software
 Listado del cumplimiento exitoso de pruebas funcionales
 Listado de todo lo planificado y pruebas que no fueron ejecutadas
 Actualizaciones para la documentación previamente liberada deberá ser revisada para
asegurar su exactitud y consistencia.
3.6.1.6 Auditoría Física
Esta verificación es realizada para verificar que el software y su documentación son internamente
consistentes y están listas para su entrega.
La verificación física compara el código con su documentación de soporte, su propósito es asegurar

que la documentación a ser entregada describa correctamente el código.
La documentación necesaria para realizar la verificación física es la siguiente:
 Descripción del diseño del software SDD

 Productos de software
 Documentación asociada
Para proveer evidencia de un adecuado control del contenido del sistema y consistencia del equipo de
auditoria se examina lo siguiente:
 Los documentos de especificación del sistema para formatos y cumplimientos

 Reportes funcionales para discrepancia y acciones tomadas
 Descripción del diseño para símbolos, etiquetas, referencias y descripción de datos
 Los manuales para formatos de completitud y cumplimiento con la descripción de
datos.
P á g i n a | 70
 Los elementos de SW liberados en el medio son óptimos para transferir y transmitir

 Identificar los cambios en los ítems de configuración de datos
3.6.1.7 Auditorías del Proceso
Estas verificaciones serán desarrolladas dentro de los procesos de desarrollo del software, como ser el
diseño para verificar la consistencia del diseño incluyendo:
 Código versus documentación del diseño

 Especificaciones de interfaces hardware / software.
 Implementación de diseño versus requerimientos funcionales
El objetivo es verificar la consistencia del producto a través del proceso del desarrollo para determinar
que:
 Las interfaces hardware/software sean consistentes con el diseño de requerimientos en

la SRS.
 Los requerimientos funcionales de la SRS, sean completamente probados por el SVVP.
 El diseño del producto especificado en la SDD, satisface los requerimientos funcionales
del SRS.
 El código es consistente con la SDD.
3.6.1.8 Revisiones de gestión
Estas revisiones son realizadas periódicamente para evaluar la ejecución del SQAP. Estas revisiones
deberán ser realizadas por el elemento organizacional del consultor.
Se podrían planificar otras revisiones, como por ejemplo la revisión de la documentación de usuario.
Para cada tipo de revisión, se debe explicar:
 Su objetivo.
 Qué producto es el que se evalúa.
 Sus propósitos.
 Cuál es el elemento organizativo responsable de llevar a cabo la revisión.
 Cuáles son los elementos organizativos que deben tomar parte de la revisión.
 Cuáles son los requisitos de revisión.
 Dónde deben documentarse los resultados de la revisión.
Para cada tipo de auditoria se debe explicar:
P á g i n a | 71
 Su objetivo.
 Cuál es el elemento organizativo responsable de llevar a cabo la auditoria.
 Dónde deben documentarse los resultados de la auditoria.
 Cuáles son las entradas para la auditoria.
Se definen los tres tipos de revisiones (Evaluación de la calidad de los productos, Revisar el ajuste al
proceso y Revisión Técnica Formal – RTF –), sus objetivos y mecanismos.
3.6.2 Evaluación de la calidad de los productos
Objetivo:
Revisar los productos que se definieron como claves para asegurar la calidad.
Detectar desviaciones en los objetivos de calidad definidos e informar a los responsables para
que sean corregidas.
Mecanismo:
Se revisan los productos para verificar que cumplan con los estándares y con los objetivos de
calidad definidas para el producto.
Se debe verificar que no queden correcciones sin resolver en los informes de revisión previos,
si se encuentra alguna no resuelta, debe ser incluida en la siguiente revisión. Se debe
identificar, documentar y seguir la pista a las desviaciones encontradas y verificar que se hayan
realizado las correcciones.
Como salida se obtiene el Informe de revisión de SQA, que contiene todas las desviaciones o
defectos encontrados durante la revisión. Este informe debe ser distribuido a los responsables
del producto y se debe asegurar que ellos son conscientes de las desviaciones o discrepancias
encontradas y de las acciones correctivas que deben realizar.
3.6.3 Revisar el ajuste al proceso
Objetivo:
P á g i n a | 72
Revisar si los productos se obtuvieron realizando las actividades que se indican en el Modelo
de Proceso.
Mecanismo:
Se revisan los productos que se definen como claves para verificar el cumplimiento de las
actividades definidas en el proceso, durante todo el ciclo de vida del software.
Se debe recoger la información necesaria de cada producto, buscando hacia atrás los productos
previos que deberían haberse generado y son entrada para el producto objeto de revisión, para
poder establecer los criterios de revisión y evaluar si el producto cumple con las
especificaciones.
Esta información se obtiene de los siguientes documentos:
 Plan del Proyecto

 Plan de la iteración
 Plan de Verificación
Se debe verificar si todos los pasos del proceso de desarrollo son seguidos apropiadamente.
Antes de comenzar, se debe verificar en los informes de revisión previos que todas las
desviaciones fueron corregidas, si no es así, las faltantes se incluyen para ser evaluadas.
Como salida se obtiene el Informe de revisión de SQA correspondiente a la evaluación de

ajuste al Proceso, que contiene todas las desviaciones o defectos encontrados durante la
revisión. Este informe debe ser distribuido a los responsables de las actividades y se debe
asegurar que ellos son conscientes de las desviaciones o discrepancias encontradas y de las
acciones correctivas que deben realizar.
3.6.4 Revisión Técnica Formal
Objetivo:
Descubrir errores en la función, la lógica o la implementación de cualquier producto del

software, verificar que satisface sus especificaciones, que se ajusta a los estándares
establecidos, señalando las posibles desviaciones detectadas.
Mecanismo:
P á g i n a | 73
Es un proceso de revisión riguroso, su objetivo es llegar a detectar lo antes posible, los posibles
defectos o desviaciones en los productos que se van generando a lo largo del desarrollo. Por
esta característica se adopta esta práctica para productos que son de especial importancia.
En la reunión participan el responsable de SQA e integrantes del equipo de desarrollo.
Se debe convocar a la reunión formalmente a los involucrados, informar del material que ellos
deben preparar por adelantado, llevar una lista de preguntas y dudas que surgen del estudio del
producto a ser revisado.
Como salida se obtiene el Informe de RTF.
3.6.5 Requerimientos mínimos
Los requerimientos mínimos que se deben observar son:

 Especificación de Requerimientos
 Modelo de Diseño y Descripción de la Arquitectura
 Plan de Verificación y Validación
 Plan de Gestión del Proyecto
 Plan de Gestión de Configuración
 Diseño vs. Especificación de requerimientos
 Implementación vs. Diseño
 Verificación vs. Especificación de requerimientos
3.6.6 Agenda
En esta sección se detallan todas las revisiones de calidad que se realizarán durante todo el proyecto,
organizadas por fase e iteración.
Fase I – Inicial
Iteración I
Entregable Realizado Revisión Tipo de revisión

P á g i n a | 74
Nombre del entregable o Tipo de revisión

Fase, iteración y Semana, si se
producto a revisar que se realizará:
semana en que se quiere también la
Evaluación de la
debe realizar la fecha, en la que se
calidad de los
versión del realizará la revisión
productos, Revisar
producto a revisar del entregable o
el ajuste al proceso
producto
o Revisión Técnica
Formal
Iteración N
3.7 Gestión de configuración
El objetivo del SQA en esta área es asegurar que se realizan las actividades de gestión de
configuración establecidas en el Plan de Configuración y que se realizan según lo establecido en el
proceso. Se pueden definir las siguientes actividades mínimas que se deberían realizar:
 Asegurar que se generó la Línea Base del proyecto en el momento establecido en el

modelo de proceso.
 Asegurar que la Línea Base del proyecto generada es correcta.
 Se verifica periódicamente que el responsable de SCM mantiene apropiadamente el
control de la línea base, así como el registro completo de cambios para requerimientos,
diseño, código, verificación y documentación.
 Se monitorean los procedimientos del Comité de Control de Cambios para verificar que
son efectivamente realizados como se especificaron en el Plan de configuración.
3.8 Información sobre problemas y acción correctiva
En esta sección se describen las prácticas y procedimientos que se van a utilizar para la notificación,
seguimiento y resolución de problemas de software, así como las responsabilidades organizativas. El
propósito de un sistema de Gestión de Problemas y Acciones Correlativas es:
 Asegurar que todos los problemas de documentan, se corrigen y no caen en el olvido.
 Asegurar que se evalúa la validez de los informes de problemas.
 Realimentar al desarrollador y el usuario sobre el estado de los problemas.

P á g i n a | 75
 Proporcionar datos para medir y predecir la calidad y fiabilidad del software.
Cualquier problema en el producto de software que sea encontrado durante el ciclo de vida de
desarrollo de software, debe ser reportado a través de un reporte en el cual se detalla la fecha de
cuando fue encontrado el problema, una identificación preliminar del mismo, descripción, etc., este
reporte debe ser firmado por los que identificaron el problema, debe ser entregado a la organización
responsable de los problemas.
La organización responsable de los problemas del software, es la organización del SQA, comandada
por la organización del consultor, estas organizaciones son las encargadas de determinar el
cronograma, lugar y temario, para llevar a fijar la acción correctiva del problema.
REPORTE FINAL DE PROBLEMAS Pág.

…......
Lugar: Hora:
a) Identificación del problema:
b) Descripción:
c) El evento ejecutado cuando se presentó el problema es:
a) Posibles orígenes del problema:

P á g i n a | 76
Equipo de Trabajo:
Nombre: Firma
Las acciones a seguir para corregir los problemas presentados se describen de la siguiente manera:
 Antes de la identificación de la presencia de un problema se debe buscar los posibles

orígenes del mismo sin desechar ninguna de las posibilidades, para esto se debe tomar dos
rutas para generar el reporte de problema completo y consistente.
o Registrar las causas sospechosas del origen del problema, esto asegura que no se
descarta ninguna situación posible.
o Registrar causas adicionales
o Registrar causas plenamente identificadas, esto es, causas verificadas por detectores
del problema
o Registrar otras causas externas o relacionadas a las identificadas anteriormente
 Generar el reporte del problema, este debe estar completamente detallado y de acuerdo a
los puntos que contiene el mismo, este reporte debe ser entregado a la organización
responsable por los problemas.
 La organización responsable por los problemas, convocan a una reunión técnica, en la cual
participarán además de la organización responsable, los elementos de las organizaciones
afectadas por el problema, quienes describirán el problema y darán recomendaciones
necesarias para solucionar el problema.
 La especificación de acciones correctivas generada en la reunión técnica, será entregada a
los elementos organizacionales afectados por el problema para que estos implementen las
acciones correctivas respectivas.
3.9 Herramientas, técnicas y metodologías
En esta sección se identifican todas las herramientas, técnicas y metodologías que se van a utilizar en
el desarrollo que apoyan el Aseguramiento de Calidad.

P á g i n a | 77
Algunas de las herramientas son:
 Utilidades del sistema operativo WINDOWS 10.
 Documentación de ayuda.
 Instaladores.
Las técnicas que ayudan a la evaluación o mejora de la calidad son:
 ANSI / IEEE – STD 830 Guide for Software Requirements Specifications
 ANSI / IEEE – STD 1016 Recommended Practice for Software Design Descriptions
 ANSI / IEEE – STD 1008 Standard for Software Unit Testing
 ANSI / IEEE – STD 1063 Standard for Software User Documentation
 ANSI / IEEE – STD 1028 Standard for Software Reviews and Audits
Las metodologías de Aseguramiento de Calidad serán conjuntos integrados de técnicas, de entre
los anteriores.
3.10 Control de código
En esta sección se definen los métodos, técnicas y facilidades que se van a utilizar para controlar el
almacenamiento y mantenimiento de versiones del código.
Se especifica un procedimiento de control del Código que:
 Defina cuál es el software que se va a controlar.
 Describa un método estándar para identificar, etiquetar y catalogar el software.
 Liste la localización física del software bajo control
 Describa la localización, forma de mantenimiento y de uso de las copias de
 seguridad.
 Describa los procedimientos para distribución de copias.

P á g i n a | 78
 Identifique la documentación que se verá afectada por los cambios.
 Describa los procedimientos para la construcción de una nueva versión.
3.11 Control de medios
En esta sección se definen los métodos y facilidades que se van a utilizar para proteger el medio
físico de accesos no autorizados y daños y degradaciones inesperadas, y las organizaciones
responsables para realizar este control.
La organización responsable por esta tarea es la organización de desarrollo, con la supervisión de
la organización de la SQA.
Se debería asegurar que:
 Está garantizado el almacenamiento y recuperación de software.
 El software está accesible únicamente para aquellos que lo necesitan.
 Se controla el entorno para que no se degrade el medio físico en el que se almacena el
software.
 Se almacenan copias del software crítico y del código en línea base fuera de las
instalaciones de la organización.
3.11.1 Medio de Almacenamiento
El medio del programa de computadora se define como aquellos medios sobre los cuales los datos son
almacenados.
Se utilizarán los siguientes medios:
 El software estará alojado en la nube, con un enlace de redireccionamiento a través de
la página dela empresa.
 La documentación respectiva sobre el desarrollo de software (papel).

P á g i n a | 79
3.11.2 Proceso de copias de seguridad
Las copias de seguridad serán realizadas a la finalización de cada sesión de trabajo, registrándose la
fecha y hora de copia de seguridad.
3.11.3 Puntos de control
Para el acceso no autorizado, se debe asignar cuentas privilegiadas, cada usuario que interactúa con el
software tendrá su propia cuenta de acuerdo al cargo que desempeñe.
Se cuenta con la integridad de la Base de Datos para la protección de los datos.
Se realizará una revisión periódica del software con el fin de que funcione óptimamente
3.12 Control de suministradores y subcontratos
En esta sección se explica de qué forma se va a asegurar que el software comprado o subcontratado
cumple los requisitos técnicos.
3.13 Recolección, mantenimiento y retención de registros
Las organizaciones responsables por las tareas de esta sección, es la organización del consultor, en
coordinación con la organización de la SQA.
Se identifica aquella documentación que se debe retener, y se especifican los métodos y facilidades
que se utilizarán para recolectar, proteger y mantener esta documentación.
También se especificará el período de retención para cada tipo de registro.
Se puede registrar no sólo documentación, sino también los medios físicos que contienen las versiones
de los programas y los materiales utilizados en las pruebas, para asegurar la repetición de los tests en
el futuro.
Los documentos que son requeridos son los siguientes:
 Plan de garantía de calidad del software.
 Especificación de requerimientos del software.

P á g i n a | 80
 Descripción del diseño del software.
 Plan de verificación y validación del software.
 Documentación del usuario.
El mantenimiento de los registros del software, será realizado por versiones sucesivas de
actualizaciones de las mismas, para esto se lleva un registro de actualizaciones de la documentación.
Los documentos verificados y validados, deben ser documentados en libros impresos, con tres copias
de cada documento y almacenado en lugares diferentes y ambiente adecuados.
La retención de registros se realizará en cada finalización de las fases del ciclo de vida de desarrollo
de software y según los puntos de verificación y validación.

P á g i n a | 81
CAPÍTULO IV:
MODELOS DE DESARROLLO EN
FORMATO DIGITAL
P á g i n a | 82
Capítulo 4: Modelos de Desarrollo en Formato Digital
4.1 Herramientas Case
4.1.1 Definición
Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de
Software Asistida por Computadora) son diversas aplicaciones informáticas o programas
informáticos destinadas a aumentar el balance en el desarrollo de software reduciendo el
costo de las mismas en términos de tiempo y de dinero.
Estas herramientas pueden ayudar en todos los aspectos del ciclo de vida de desarrollo del
software en tareas como el proceso de realizar un diseño del proyecto, cálculo de costos,
implementación de parte del código automáticamente con el diseño dado, compilación
automática, documentación o detección de errores entre otras. Ya en los años 70 un
proyecto llamado ISDOS diseñó un lenguaje y por lo tanto un producto que analizaba la
relación existente entre los requisitos de un problema y las necesidades que estos
generaban, el lenguaje en cuestión se denominaba PSL (Problem Statement Language) y la
aplicación que ayudaba a buscar las necesidades de los diseñadores PSA (Problem
Statement Analyzer). Aunque ésos son los inicios de las herramientas informáticas que
ayudan a crear nuevos proyectos informáticos, la primera herramienta CASE fue
Excelerator que salió a la luz en el año 1984 y trabajaba bajo una plataforma PC.
Las herramientas CASE alcanzaron su techo a principios de los años 90. En la época en la
que IBM había conseguido una alianza con la empresa de software AD/Cycle para trabajar
con sus mainframes o computadoras centrales, estos dos gigantes trabajaban con
herramientas CASE que abarcaban todo el ciclo de vida del software. Pero poco a poco los
mainframes han ido siendo menos utilizados y actualmente el mercado de las Big CASE ha
P á g i n a | 83
muerto completamente abriendo el mercado de diversas herramientas más específicas para
cada fase del ciclo de vida del software.
4.2 Visual Studio Code
Visual Studio Code es un editor de código fuente desarrollado por Microsoft para
Windows, Linux y macOS. Incluye soporte para la depuración, control integrado de Git,
resaltado de sintaxis, finalización inteligente de código, fragmentos y refactorización de
código. También es personalizable, por lo que los usuarios pueden cambiar el tema del
editor, los atajos de teclado y las preferencias. Es gratuito y de código abierto,12 aunque la
descarga oficial está bajo software propietario.
Visual Studio Code se basa en Electron, un framework que se utiliza para implementar
aplicaciones Node.js para el escritorio, que se ejecuta en el motor de diseño Blink. Aunque
utiliza el framework Electron, el software no usa Atom y en su lugar emplea el mismo
componente editor (Monaco) utilizado en Visual Studio Team Services (anteriormente
llamado Visual Studio Online).

P á g i n a | 84
4.2.1 Características
Destacamos los siguientes puntos en todo lo que nos ofrece Visual Studio Code:
 Lenguajes de programación: La edición de código no está limitada para C# y VB
(lenguajes propietarios de Microsoft) si no que de nueva cuenta el Open Source
está en el paquete: Java, Go, C, C++, Ruby, Python, PHP, Perl, JavaScript,
Groovy, Swift, PowerShell, Rust, DockerFile, CSS, HTML, XML, JSON, Lua, F#,
Batch, SQL, Objective-C.
 Multiplataforma: Fue creado y diseñado para que funcione en los tres
 sistemas operativos mayormente utilizados: Windows, Linux y Mac OS. Basta con
entrar al web site oficial, y descargar los binarios correspondientes.
 Plugins: VS Code es una herramienta que se actualiza constantemente, tiene la
posibilidad de adaptar plugins para trabajar con el cómputo en la nube de
Microsoft Azure y desplegar proyectos directamente.
 Intellisense: Se le denomina «Intellisense» a la capacidad que tiene un editor de
texto para predecir la instrucción que estamos por escribir, y con esto no tenemos
la necesidad de escribir toda la instrucción, ya que esta se puede autocompletar con
el editor, esto nos hace más productivos y acorta la posibilidad de errores de
sintaxis.
 Open Source: VS Code se encuentra en la red social de desarrolladores más
popular del momento «GitHub «, por lo que podemos bajarlo a nuestra
computadora, analizar el código, hacer cambios y enviarlos mediante Git al equipo
de Microsoft para que los valore y si cree conveniente, incluirlo como Core del
producto.
P á g i n a | 85
En el apartado de las compilaciones, nos permite trabajar con el código, pero está separado
del compilador, por lo que solo podemos editar o crear nuevo código. Las plantillas que se
encuentran en Visual Studio ayudan a construir la estructura base de los proyectos, con VS
Code también podemos crearlos, pero siempre desde cero.
4.3 Sparx Systems Enterprise Architect
Sparx Systems Enterprise Architect es una herramienta de diseño y modelado visual
basada en OMG UML. La plataforma soporta: el diseño y construcción de sistemas de
software; modelado de procesos de negocio; y modelado de dominios basados en la
industria. Es utilizado por empresas y organizaciones no solo para modelar la arquitectura
de sus sistemas, sino también para procesar la implementación de estos modelos durante
todo el ciclo de vida del desarrollo de la aplicación.
El modelado de sistemas utilizando UML proporciona una base para modelar todos los
aspectos de la arquitectura organizacional, junto con la capacidad de proporcionar una base
para diseñar e implementar nuevos sistemas o cambiar sistemas existentes. Los aspectos
que pueden ser cubiertos por este tipo de modelado abarcan desde el diseño de arquitecturas
organizacionales o de sistemas, la reingeniería de procesos de negocios, el análisis de
negocios y las arquitecturas orientadas a servicios y el modelado web, hasta el diseño y la
base de datos de aplicaciones y bases de datos. -Ingeniería, y desarrollo de sistemas
embebidos. Junto con el modelado de sistemas, Enterprise Architect cubre los aspectos
centrales del ciclo de vida del desarrollo de la aplicación, desde la gestión de requisitos
hasta las fases de diseño, construcción, prueba y mantenimiento, con soporte para la
trazabilidad, gestión de proyectos y control de cambios de estos procesos. así como,
instalaciones para el desarrollo basado en modelos de código de aplicación utilizando una
plataforma interna de desarrollo integrado.

P á g i n a | 86
4.3.1.1 Gestión de Requisitos
Las características comunes de la Gestión de requisitos soportada por Enterprise
Architect incluyen la personalización de cómo se documentan los requisitos, vincular los
requisitos con los detalles de diseño e implementación, y proporcionar la Trazabilidad de
los requisitos a través de las fases de diseño y construcción. Estos requisitos pueden estar
sujetos a gestión de cambios, procesamiento del flujo de trabajo, comparación de referencia
y auditoría.
4.3.1.2 Modelización y análisis de negocios
Enterprise Architect admite varios métodos de modelado de procesos de negocios
utilizando UML como el lenguaje de modelado de base. Los lenguajes principales para el
modelado y análisis de negocios incluyen BPMN y BPEL , junto con varios perfiles
históricos. Enterprise Architect también admite la definición de Reglas de negocios con la
capacidad de generar código ejecutable a partir de estas reglas. El modelo de negocios se
puede combinar con el análisis de brechas para ver las brechas potenciales en las soluciones
propuestas.
4.3.1.3 Simulación
La simulación de modelo es compatible con:
 Diagramas de comportamiento:
o Máquinas de estado
o Interacción (diagramas de secuencia)

P á g i n a | 87
o Ocupaciones
 El flujo de ejecución se define utilizando Desencadenadores, Guardias y Efectos. La
simulación admite repeticiones con alteración de los eventos activados y admite
variables de visualización, la pila de llamadas y la configuración de marcadores de
depuración. También se admite la interacción con pantallas de interfaz de usuario
emuladas que contienen campos de IU comunes.
 Diagramas BPMN: Uso de BPSim: los modelos BPMN pueden simularse creando
resultados tabulados para el análisis. Soporta simulaciones basadas en la
probabilidad de Monte Carlo.
 Simulación paramétrica de SysML: Usando Open Modelica, se pueden
 simular fórmulas matemáticas en bloques SysML y bloques paramétricos para trazar
gráficos utilizados en el análisis.
 Simulación DMN: Los modelos basados en reglas y hechos de DMN se pueden
simular y el código se puede generar a partir de los modelos para su reutilización.
La simulación admite la interacción entre modelos DMN y modelos BPMN
utilizando BPSim.
4.3.1.4 Desarrollo del Sistema
De acuerdo con los principios de diseño de Model Driven, Enterprise Architect admite
transformaciones MDA de estructuras de clase PIM a estructuras de clase PSM , ingeniería
de ida y vuelta de código para 10 lenguajes de software y varios lenguajes de sistemas HDL
incrustados ( Ada , VHDL y Verilog ). También es compatible con la generación de código
a partir de modelos de comportamiento. Lenguajes de programación soportados:
 ActionScript
P á g i n a | 88
 do
 C # (para .NET 1.1 y .NET 2.0)
 C ++ (estándar, más las extensiones de C ++ administradas por .NET)
 Delphi
 Java (incluyendo Java 1.5, Aspectos y Genéricos)
 PHP
 Pitón
 Visual Basic
 Visual Basic .NET
Compiladores e intérpretes soportados:
 Microsoft Windows Native C
 Microsoft Windows Native C ++
 Microsoft Windows Visual Basic
 Familia Microsoft .NET (C #, J #, VB)
 Sun Microsystems Java.
 PHP
 Compiladores GNU para C ++, C y Ada (GCC y GDB)
4.4 Gestión de Pruebas
Para las pruebas basadas en código hay soporte para:
 xUnit Testing: Esto implica la transformación MDA de las Clases en NUnit o Junit
Classes con la capacidad de generar pruebas unitarias a partir del modelo y registrar
automáticamente los resultados contra las Clases probadas.

P á g i n a | 89
 Prueba de testFlutter: Este es un modelo basado en pruebas de código Dart, el cual
ayuda a realizar las pruebas respectivas al código de flutter.
4.5 Modelado de datos
Enterprise Architect admite el modelado de datos desde los niveles conceptual a
físico, la ingeniería directa e inversa de esquemas de base de datos, y la transformación
MDA de la lógica (independiente de la plataforma) a la física DBMS (depende de la
plataforma). Los tipos de diagramas soportados incluyen:
 Notación DDL
 Notación ERD
 Notación IDEF1X
 Notación de la ingeniería de la información.
DBMS soportados:
 DB2
 Firebird / InterBase
 MS Access 97, 2000, 2003, 2007, 2013
 MS SQL Server, todas las ediciones de 2005, incluidas Express y Azure
 MySQL
 Mariadb
 SQLite
 Oracle desde 9i (todas las ediciones)
 PostgreSQL
 ArcGIS
 Informix
P á g i n a | 90
 Ingres
CAPÍTULO V:
ASPECTOS LEGALES PARA LA
APERTURA DE UNA EMPRESA
DE DESARROLLO
P á g i n a | 91
Capítulo 5: Aspectos Legales para la apertura de una empresa de

Desarrollo
5.1 Aspectos legales a cumplir
Para crear una empresa de alto desempeño competitivo es necesario ser reconocido por el
marco institucional que regula la actividad empresarial.
Esta Guía le brinda la manera de conseguir ese reconocimiento: Que trámites necesita,
donde conseguirlos y en que secuencia ejecutarlos.
El camino de la formalidad consiste en 6 pasos, cada uno en una institución específica y de
acuerdo a la constitución legal de su empresa.
Estos son los pasos que hay que seguir uno a uno para lograr y tener un aspecto legal al
momento de empezar una empresa que a medida que avance se ira desglosando uno a uno
para tener una mejor apreciación de cómo se mantiene y se puede emprender con una nueva
empresa.
5.2 Fundempresa
Para registrar una empresa necesitas lo siguiente:
5.2.1 Trámite de control de homonimia
Primero, verifique la disponibilidad del nombre que utilizará su empresa, mediante el
trámite de Control de Homonimia.
CONTROL DE HOMONIMIA
Concepto del A fin de establecer si el nombre no se encuentra registrado por otra
Trámite: empresa dentro de la misma actividad económica, el trámite de control de
homonimia se constituye en el mecanismo operativo del cliente para
conocer la viabilidad del uso del nombre.

P á g i n a | 92
Usuario al que va Comerciantes: empresas unipersonales y sociedades comerciales.
dirigido:
Normas legales que D. L. 14379 Código de Comercio.

D. S. 26215 Reglamento de la Concesión de Registro de Comercio
regulan el trámite:
Empresa Unipersonal o Comerciantes Individuales

Tipo societario
Sociedad de Responsabilidad Limitada
Sociedad Anónima Bs.175
Duración máxima 1 día hábil, que se cuenta desde el día siguiente al día en que se ingresó el
regulada por norma trámite
legal (en días)
INSTITUCIÓN FUNDEMPRESA
DONDESE
TRAMITA:
Unidad u otra Registro de Comercio de Bolivia
Denominación:
P á g i n a | 93
5.2.2 Requisitos
Descripción del Formulario N° 0010 de solicitud de Control de Homonimia,
Requisito debidamente llenado y firmado por el cliente
Costo del Requisito Bs Sus UFVs
Sin Costo
5.2.3 Inscripción de la empresa en el registro de comercio
Siguiente paso es la inscripción de su empresa en el Registro de Comercio de acuerdo
al tipo societario que tendrá su empresa:
 Empresa Unipersonal o Comerciantes Individuales
 Sociedad de Responsabilidad Limitada
 Sociedad Anónima
TRÁMITE: REGISTRO DE COMERCIO
Concepto del Trámite: Le otorga la Matrícula de Comercio, a través
de la cual usted adquiere la
calidad de comerciante con
reconocimiento legal del Estado para
desarrollar sus actividades
empresariales
Usuario al que va dirigido: Todos los comerciantes: empresas
unipersonales y sociedades comerciales.
Normas legales que regulan el trámite: D. L. 14379 Código de Comercio
D. L. 16833 Reglamento de la Dirección

P á g i n a | 94
General de Registro de Comercio y
Sociedades por Acciones
D. S. 26215 Reglamento de la Concesión de
Registro de Comercio
Costo (en la moneda regulada)
Empresa Unipersonal o Comerciantes Individuales Bs.260
Sociedad de Responsabilidad Limitada Bs.455
Sociedad Anónima Bs.584,5
Vigencia Hasta 150 días posteriores a la fecha de cierre
fiscal que corresponda a su actividad.
Tiempo de procesamiento: Empresa Unipersonal o C o m e r c i a n t e s 2
días Individuales hábiles. Sociedad de
Responsabilidad limitada
INSTITUCIÓN DONDE SE FUNDEMPRESA
TRAMITA:
Unidad u otra Denominación: Registro de Comercio de Bolivia

P á g i n a | 95
REQUISITOS
De acuerdo al tipo de empresa
Empresa Unipersonal o Comerciantes Individuales
Sociedad de Responsabilidad Limitada
Sociedad Anónima
EMPRESAS UNIPERSONALES O COMERCIANTES INDIVIDUALES
Si el capital inicial es igual o menor a Bs. 27.735
Formulario de Declaración Jurada N° 0020 de solicitud de Matrícula de
Comercio debidamente llenado y firmado por el propietario o representante
legal de la empresa.
Cédula de identidad original del comerciante o propietario (únicamente para
verificación) y Fotocopia simple de cédula de identidad del comerciante.
Si el capital inicial es igual o mayor a Bs.27.736
Comercio debidamente llenado y firmado por el propietario o representante
legal de la empresa.
Cédula de identidad original del comerciante o propietario (únicamente para
verificación) y fotocopia simple de cédula de identidad del comerciante.
Balance de Apertura firmado por el propietario o representante legal y el
profesional que interviene, acompañando la solvencia profesional original
otorgada por el Colegio de Contadores o Auditores.
SOCIEDADES DE RESPONSABILIDAD LIMITADA

P á g i n a | 96
Comercio debidamente llenado y firmado por el representante legal de la
empresa.
Balance de apertura firmado por el representante legal y el profesional que
interviene, acompañando la solvencia profesional original otorgado por el
Colegio de Contadores o Auditores.
Testimonio de escritura pública de constitución social en original o fotocopia
legalizada legible. El mencionado instrumento debe contener los aspectos
previstos en el Art. 127 del Código de Comercio y adecuarse a las normas
correspondientes al tipo societario.
Publicación del testimonio de constitución en un periódico de circulación
nacional que contenga las partes pertinentes referidas: a) introducción notarial
de la escritura pública en la que conste el N° de instrumento, lugar, fecha,
Notaría de Fe Pública y Distrito Judicial; b) Transcripción in extenso y
textual de las cláusulas establecidas en los incisos 1 al 7 del Art. 127 del
Código de Comercio y c) conclusión y concordancia de la intervención del
Notario de Fe Pública. Adjuntar página completa del periódico en que se
efectúa la publicación.
Testimonio de poder del representante legal original o fotocopia legalizada
legible, para el caso en el que la escritura pública de constitución no
determine el nombramiento del mismo.
SOCIEDAD ANÓNIMA
P á g i n a | 97
Comercio debidamente llenado y firmado por el representante legal de la
empresa.
Balance e apertura firmado por el representante legal y el profesional que
interviene, acompañando la solvencia profesional original otorgado por el
Colegio de Contadores o Auditores.
Testimonio de la escritura pública de constitución social, en original o
fotocopia legalizada legible, con la inserción del acta de fundación de la
sociedad que contenga la resolución de aprobación de estatutos y designación
del directorio provisional. El mencionado instrumento debe contener los
aspectos previstos en el Art. 127 del Código de Comercio.
Estatuto de la sociedad, el mismo que puede ser insertado en la escritura
constitutiva o instrumentalizado por separado en un testimonio notarial.
Publicación del testimonio de constitución en un periódico de circulación
nacional que contenga las partes pertinentes referidas a: a) introducción
notarial de la escritura pública en la que conste el N° de instrumento, lugar,

P á g i n a | 98
fecha, Notaría de Fe Pública y Distrito Judicial; b) Transcripción in extenso y
textual de las cláusulas establecidas en los incisos 1 al 7 del Art. 127 del
Código de Comercio y c) conclusión y concordancia de la intervención del
Notario de Fe Pública. Adjuntar página completa del periódico en que se
efectúa la publicación.
Testimonio de poder del representante legal original o fotocopia legalizada
legible que contenga el acta de su nombramiento, para el caso en el que la
escritura pública de constitución no determine el nombramiento del mismo
Certificado de depósito bancario emitido por cualquier entidad financiera del
país, que consigne el cantal pagado en dinero. La cuenta corriente bancaria
debe estar a nombre de la sociedad en formación.
CIUDAD(ES) EN QUE A nivel Nacional
SE ATIENDE:
P á g i n a | 99
Oficina La Paz Av. Mariscal Santa Cruz N.º 1392

Lugar de
Atención: Edif. Cámara Nacional de Comercio 2º
Mezanine.
Oficina El Alto Av. 6 de marzo S/N Edif. Fundación INFOCAL
Bloque E, Piso 1
Oficina Santa Cruz
Av. Las Américas N.º 7
Edif. Torre CAINCO
Segunda Oficina
Oficina Montero
Calle Sucre N° 155
Oficina Cochabamba
El Prado, Av. Ballivián Nº 638
Esq. España, Segundo Piso.

P á g i n a | 100
5.3 Servicio de Impuestos Nacionales
Pertenecer al universo de contribuyentes es uno de los pasos más importantes hacia la
formalidad. Su empresa puede convertirse en sujeto de crédito y a la vez acceder a los
mercados internacionales.
TRAMITE Número de Identificación Tributaria
Concepto del Trámite: Para iniciar cualquier actividad económica.
Usuario al que va Personas Naturales y Jurídicas
dirigido
Normas legales que Ley 843 - Ley 1606, Resolución administrativa 05-
P á g i n a | 101
regulan el trámite: 187-98 y Circulares 54, 55 de la Gerencia General
del SIN.
Costo (en la moneda Sin costo
regulada):
Duración máxima 13 min.
regulada por norma legal
(en días) o calculada por la
Institución:
Institución donde se SERVICIO DE IMPUESTOS NACIONALES
tramita:
Unidad u otra Departamento de Empadronamiento y
Denominación: Recaudaciones-Gerencias Distritales
5.3.1 Requisitos
 NIT según régimen impositivo
 Modificaciones al NIT
5.3.1.1 NIT
5.3.1.1.1 Régimen General
5.3.1.1.1.1 Persona Natural
 Formulario de Empadronamiento
 Documento de identificación del titular
 Balance de apertura (Solo si corresponde a una empresa unipersonal)

P á g i n a | 102
 Factura de luz que acredite al domicilio
 Contrato de trabajo sobre la base de términos de referencia definidos por la
institución contratante solo en casos de consultores, contratados por el sector
público.
5.3.1.1.1.2 Personas Jurídicas
 Formulario de empadronamiento.
 Escritura de constitución de Sociedad o Personería Jurídica, Ley, Decreto Supremo
o Resolución según corresponda, Fotocopia Legalizada.
 Documento de identificación titular.
 Factura de luz que acredite el domicilio.
 Balance de Apertura.
 Representante Legal
 Fuente de mandato (Poder, Acta de Dirección, Estatuto o Contrato). Fotocopia
legalizada
 Documento de identidad
 Factura de luz
 Para las actividades se debe adicionar los siguientes requisitos
 Licencia de funcionamiento que acredita la actividad de turismo receptivo que
desempeña
5.3.1.1.1.3 Sucesión indivisa
 Formulario de empadronamiento
 Declaración de herederos o testamento
 Certificado de defunción
P á g i n a | 103
 Factura de luz que acredite el domicilio
5.3.1.1.2 Régimen Tributario Simplificado
 Documento de Identidad, original y fotocopia
 RUA o póliza tributaria del Automotor (PTA)
5.3.1.1.3 Régimen Tributario Integrado
5.3.1.1.3.1 Personas naturales propietarias de hasta dos vehículos
 Documento de identidad, original y fotocopia
 RUA
5.3.1.1.4 Régimen Agropecuario Integrado
5.3.1.1.4.1 Personas Naturales
 Documento de Identidad y Fotocopia
 Título de propiedad o documento que certifique la propiedad o su derecho de
explotación
5.3.1.1.4.2 Cooperativas
 Documento de Identidad y Fotocopia
 Título de propiedad o documento que certifique la propiedad o su derecho de

P á g i n a | 104
explotación
P á g i n a | 105
5.3.1.1.4.3 Sucesión Indivisa
 Declaración de herederos o testamento
 Certificado de defunción
5.3.1.2 Modificaciones al NIT
5.3.1.2.1 Datos Básicos – Personería Jurídica
5.3.1.2.1.1 Razón Social
 Formulario de modificación
 Testimonio de modificación de escritura de constitución de sociedad de personería
Jurídica
 Devolución de cedula y certificado
 Declaración jurada de devolución de notas fiscales no utilizadas si corresponde
5.3.1.2.1.2 Origen de entidad composición de capital
Jurídica
5.3.1.2.1.3 Fecha de reconocimiento de persona jurídica
Jurídica
P á g i n a | 106
5.3.1.2.1.4 Carácter de entidad
Jurídica
5.3.1.2.2 Empresa natural a empresa unilateral
 Balance de apertura
5.3.1.2.3 Empresa unipersonal a empresa natural
 Formulario de medicación
 Balance de cierre
 Devolución de NIT
 Carnet de Identidad
 Devolución de Factura
5.3.1.2.4 Modificación de régimen
 Documentos de Identificación de titular
 Balance de Apertura (solo sí corresponde a una Empresa Unipersonal)
 Factura de Luz, que acredite el domicilio
5.3.1.2.5 Actividades económicas
5.3.1.2.5.1 Alta o modificación de actividades

P á g i n a | 107
Jurídica
 NIT del representante legal y Poder del Representante Legal
5.3.1.2.5.2 Baja de actividades
 Declaración Jurada de devolución de notas Fiscales no utilizadas, si corresponde,
(solicitud de Anulación / Devolución de Facturas, Formulario 3348)
 Devolver NIT
5.3.1.2.6 Características Tributarias
 Decreto Supremo o Resolución, si la actividad corresponde a una Zona Franca.
 Licencia de funcionamiento que acredite la actividad de Turismo Receptivo, sólo en
caso que se posea esa actividad.
 Contrato de Trabajo, en base a términos de referencia definidos por la institución
contratante (sólo en caso de consultores, contratados por el sector público -
Personas Naturales).
Ciudades donde se Atiende A Nivel Nacional
Lugar de Atención
Gerencia Distrital LA PAZ Dirección: Dirección: Av.
Montes N° 515 ex Cia. de Tabacos
Tarija- Av. Victor Paz Estensoro No. 184
Días y horarios de atención De lunes a viernes, de 8:30 a 4:30
Alcance del tramite Nivel Nacional

P á g i n a | 108
Consultas de Teléfonos Gerencia Distrital EL ALTO Teléfono (s): 2820984
2821765 Fax: 2821765
Gerencia Distrital LA PAZ Teléfono (s): 2311753
2311725 2390186 Fax: 2332618
Gerencia Distrital COCHABAMBA Teléfono (s):
4501326 Fax: 4501326
Gerencia Distrital SANTA CRUZ Teléfono (s): 3362025
- 3362127 Fax: 3324412
Gerencia Distrital POTOSI Teléfono (s): 6222526
6227413 - 62299441 Fax: 6223820
Gerencia Distrital ORURO Teléfono (s): 2524006 Fax:
5279681
Gerencia Distrital CHUQUISACA Teléfono (s):
46453086 Fax: 46453086
Gerencia Distrital TARIJA Teléfono (s): 6641481 Fax:
6112289
Gerencia Distrital BENI Teléfono (s): 4622954 4621396
4621938
Fax: 4652196
Gerencia Distrital PANDO Teléfono (s): 8422289 Fax:

P á g i n a | 109
8422802
Observaciones La entrega del NIT es inmediata, luego la empresa para
indicar el inicio de sus actividades deberá presentar su
balance de apertura dentro del plazo de 20 días para
Empresas de Sociedad Anónima.
5.3.2 Gobierno Municipal
El objetivo del trámite es certificar la apertura de una actividad económica. Están
incluidas todas las actividades comerciales y de servicio, al igual que las entidades,
organismos o asociaciones culturales, deportivas, religiosas y sociales sin fines de lucro. El
usuario puede obtener los formularios utilizando su número de NIT y el nombre que
acompaña a este ya sea una persona natural o jurídica.
TRAMITE LICENCIA DE FUNCIONAMIENTO PARA
ACTIVIDADES ECONOMICAS
Concepto del Trámite: Licencia de Funcionamiento para Actividades Económicas
Usuario al que va Personas naturales y jurídicas
dirigido:
Costo (en la moneda Sin costo
regulada):
Vigencia 1 Año.
Tiempo de procesamiento:
Actividades Económicas en General: 30

P á g i n a | 110
Min
Expendio de alimentos, bebidas alcohólicas y juegos electrónicos: 48
Has
REQUISITOS
1. Cédula de Identidad, RUN o RIN y fotocopia.
2. Fotocopia del NIT o Inscripción del Régimen Simplificado.
3. Croquis de distribución de ambientes del local.
4. Última factura de luz local.
5. Recabar y llenar el Formulario Único de Licencias de Funcionamiento
(FULF).
6. Recabar y llenar el Formulario 401 en caso de no contar con el Padrón
Municipal del Contribuyente.
7. Recabar y llenar el Formulario 402, si cuenta con el Padrón Municipal del
Contribuyente.
Los requisitos anteriormente citados son suficientes para abrir una empresa unipersonal, si
desea abrir una empresa S.R.L. o S.A. deberá cumplir con los requisitos 5 y 6 del cuadro
siguiente, asimismo para ciertas clases de actividad económica se necesitan permisos
adicionales. Los requisitos pueden variar de acuerdo a cada municipio.
NOTA: Para otorgar la licencia de funcionamiento una vez cubiertos todos los
requerimientos y previa el otorgamiento de la Licencia de Funcionamiento, el gobierno
municipal efectuara una inspección que verificara las condiciones técnicas (conexiones
de gas, luz, agua, etc.) ambientales (ruidos), laborales, higiene, salubridad. Aprobando o
P á g i n a | 111
rechazando la solicitud de Licencia de Funcionamiento

P á g i n a | 112
CIUDADES A NIVEL NACIONAL
Lugar de Atención: Gobierno Municipal de La Paz
Calle Mercado Esq. Colón
Gobierno Municipal de El Alto
Zona Calama, Frente a la plaza Bandera, Parroquia San Juan
Bautista
Gobierno Municipal de Santa Cruz
Plaza 24 de Septiembre, Acera Norte
Av. Cañoto entre Ingavi y Ayacucho, Edif. Cordova Planta Baja
Gobierno Municipal de Cochabamba
Plaza 14 de Septiembre
Gobierno Municipal de Colcaphirua
Av. Blanco Galindo Plaza 15 de Abril
Gobierno Municipal de Oruro
Plaza 10 de Febrero
Gobierno Municipal de Sucre
Plaza 25 de Mayo No 1
Gobierno Municipal de Tarija
Calle 15 de abril entre Sucre y General Trigo
Días y Horarios de De lunes a viernes, de horas 8:30 a 12:30 y 14:30 a 18:30

P á g i n a | 113
Atención:
5.3.3 Caja de Salud
Las empresas deben inscribirse a sus empleados a la Caja Nacional de Salud para cumplir
con las normas sociales vigentes de acuerdo a la norma legal que posean, de la misma
manera un trabajador que desee incorporarse a la caja de forma voluntaria también puede
hacer sus consultas.
 Afiliación de una Sociedad Anónima o una Sociedad de Responsabilidad Limitada
 Afiliación Empresa Unipersonal
 Afiliación del Trabajador
Trámite: AFILIACIÓN EN LA CAJA NACIONAL DE SALUD
Concepto del Afiliación de empleados de una empresa en la Caja Nacionalde
Trámite: Salud.
Usuario al que va Personas naturales o jurídicas.
dirigido:
Costo (en la moneda regulada):
Empresa Unipersonal o Comerciantes Individuales8
Bs. Sociedad de Responsabilidad Limitada 8
Bs.
Sociedad Anónima 8 Bs.
Vigencia Dependiendo de la empresa (Altas o Bajas).

P á g i n a | 114
Tiempo de procesamiento:
Empresa Unipersonal o Comerciantes Individuales: 2 día hábil.
Sociedad de Responsabilidad Limitada: 3 días hábiles.
Sociedad Anónima: 3 días hábiles.
INSTITUCIÓN CAJA NACIONAL DE SALUD
DONDE SE
TRAMITA:
Unidad u otra Ventanilla Única
Denominación:
REQUISITOS
 Sociedad Anónima o Sociedad de Responsabilidad Limitada
 Empresa Unipersonal
 Trabajador
SOCIEDAD ANÓNIMA Y SOCIEDAD DE RESPONSABILIDAD LIMITADA
 Formulario AVC 01 (llenado).
 Formulario AVC-02 (vacío).
 RCI-1A (llenado las 2 primeras filas y el mes).
 Carta de solicitud dirigida al Dr. José Romero Vera.
 Fotocopia C. I. Representante Legal.

P á g i n a | 115
 Fotocopia NIT.
 Balance de Apertura Aprobado y Sellado por el SIN*.
 Testimonio de Constitución si es en Sociedad.
 Planilla de Haberes original y copia.
 Nómina de Personal con fecha de nacimiento.
 Croquis de ubicación de la Empresa.
*En caso de no contar con el balance de apertura, también se admite el balance de gestión.
EMPRESAS UNIPERSONALES
 Formulario AVC 01 (llenado).
 Formulario AVC-02 (vacío).
 RCI-1A (llenado las 2 primeras filas y el mes).
 Carta de solicitud dirigida al Dr. José Romero Vera.
 Fotocopia C.I. Representante Legal.
 Fotocopia NIT.
 Planilla de Haberes original y copia.
 Nómina de Personal con fecha de nacimiento.
 Croquis de ubicación de la Empresa.
TRABAJADOR
 Formulario Avc-04 "aviso de afiliación del trabajador".
 Formulario Avc-05 "cedula del trabajador".
 Fotocopia cédula de identidad del trabajador.
 Certificado de nacimiento original.

P á g i n a | 116
 Última papeleta de pago - original.
CIUDADES A nivel Nacional
Lugar de Atención: Capitales de departamento
Días y Horarios de Atención: De lunes a viernes, de horas 8:30 a 12:30 y 14:30 a
18:30.
Alcance del Trámite: Nivel Nacional
Observaciones: Ninguna
5.3.4 AFPS
Las Administradoras de Fondos de Pensiones son las encargadas de administrar los
recursos de los trabajadores cuando los mismos lleguen a una edad avanzada. El principal
objetivo es incrementar el nivel de ahorro del país, de acuerdo a las leyes vigentes, todas las
empresas están obligadas a registrarse ante las AFP's. Actualmente existen dos AFP's
vigentes.
 AFP Previsión http://www.prevision.com.bo
 AFP Futuro http://www.afp-futuro.com
Concepto del Trámite: Registro en la AFP
Usuario al que va dirigido: Personas naturales y jurídicas
Normas legales que Ley Nº 2427: Ley de Bonosol

P á g i n a | 117
regulan el trámite:
REQUISITOS
 AFP PREVISION
 AFP FUTURO
AFP PREVISIÓN
Registro de Empresas.
Es un registro obligatorio de un empleador a una Administradora de Fondos de Pensiones
(AFP), con el objetivo fundamental de crear un vínculo laboral para su personal
dependiente afiliado al Seguro Social Obligatorio (S. S. O.) de largo plazo.
 Llenar Formulario de Inscripción del Empleador.
 Fotocopia del NIT.
 Fotocopia del Documento de Identidad del Representante Legal.
Registro de Personas.
El registro es la concreción de la afiliación, la misma que se da una vez que el afiliado
procede al llenado y firma del Formulario de Registro y se obtiene un número único
asignado (NUA) por parte de la AFP. Todas las personas con relación de dependencia
laboral deben registrarse de manera obligatoria a una de las AFPs. Todo empleador tiene
la obligación de registrar a sus dependientes en un plazo máximo de veinticinco
(25) días después de iniciada la nueva relación laboral.

P á g i n a | 118
AFP FUTURO
Registro de Empresas
Es un registro obligatorio de un empleador a una Administradora de Fondos de Pensiones
(AFP), con el objetivo fundamental de crear un vínculo laboral para su personal
dependiente afiliado al Seguro Social Obligatorio (S. S. O.) de largo plazo.
Registro de Personas
El registro es la concreción de la afiliación, la misma que se da una vez que el afiliado
procede al llenado y firma del Formulario de Registro y se obtiene un número único
asignado (NUA) por parte de la AFP. Todas las personas con relación de dependencia
laboral deben registrarse de manera obligatoria a una de las AFPs. Todo empleador tiene
la obligación de registrar a sus dependientes en un plazo máximo de veinticinco
(25) días después de iniciada la nueva relación laboral.
CIUDADES A nivel Nacional

P á g i n a | 119
Lugar de AFP FUTURO
Atención: Oficina La Paz
Plaza del Estudiante, Edif. Inchauste Zelaya No 1940, Planta Baja
Oficina El Alto
Av. Jorge Carrasco No 10 entre Calles 1 y 2
Oficina Cochabamba
Calle Nataniel Aguirre No.455 entre Jordán y Calama
Oficina Santa Cruz
Calle Warnes esq. René Moreno s/n
Oficina Oruro
Calle presidente Montes
Nº 1486A y Adolfo Mier
Oficina Trinidad
Nicolás Suárez esq. Plaza Ballivián Edif. Club Social 18 de
Noviembre
Oficina Cobija
Calle Nicolás Suarez Nº 079
Oficina Riberalta
Calle Monseñor Santisteban No 271
AFP PREVISA
Oficina La Paz
Av. 6 de agosto esq. campos Edif. El Ciprés

P á g i n a | 120
Oficina El Alto
Av. Franco Valle N.º 42 casi esq. calle 2 Edif.
Fundación INFOCAL
Bloque B-7, Piso 2
Oficina Santa Cruz
Edif. Equipetrol Av. San Martín esq. 2Âº anillo
Oficina Cochabamba
Av. Constitución N.º 810 Edif. Clan II
Oficina Sucre
Calle Bolívar Ni 579
Oficina Tarija
Calle La Madrid N.° 264
Oficina Potosí
Calle Lanza N.° 29

P á g i n a | 121
5.3.5 Fundempresa
TRAMITE Solicitud de Inscripción en el registro de empleadores
Concepto del Trámite: Permite obtener el Certificado de Inscripción en el
Registro de Empleadores del Ministerio de Trabajo, que
autoriza la utilización del Libro de Asistencia y/o Sistema
Alternativo de Control de Personal, así como la apertura del
Libro de Accidentes. En cumplimiento de las normas legales
vigentes en el país, el Empleador y/o Empresa inscritos en el
mencionado Registro, deberá presentar obligatoriamente el
trámite de Visado de Planillas Trimestrales de Sueldos y
Salarios.
Usuario al que va dirigido: Empleadores, empresas e instituciones legalmente
constituidas y domiciliadas en Bolivia.
Normas legales que regulan Ley del Poder Ejecutivo N. º 2446. Resolución Ministerial
N. º 002/04.
el trámite:
Costo (en la moneda Bs. 80
regulada):
Duración máxima regulada 1 día hábil.
por norma legal (en días) o
calculada por la
Institución:
Ministerio de Trabajo
Viceministerio Viceministerio de Trabajo

P á g i n a | 122
Dirección General Dirección General del Trabajo y Direcciones
Departamentales del Trabajo.
Unidad u otra Unidad de Planillas y salarios.
Denominación:
REQUISITOS
 Llenado de Declaración Jurada (Formulario Único de Registro de Empleadores
original y una copia)
 Última Planilla Salarial de los Trabajadores
 Bolera de Depósito de Bs. 50 (Cincuenta Bolivianos 00/100) en la cuenta N° 201-
0448901-3-85 del Banco de Crédito de Bolivia a nombre del Ministerio de Trabajo
Lugar de Atención: La Paz, Calle Bueno #333 segundo piso
Días y horarios de atención: De lunes a viernes de 8:30 a 16:30.
Alcance del Trámite: El certificado de Inscripción en el Registro de Empleadores
del Ministerio de Trabajo tiene alcance a nivel nacional.
Teléfonos de Consulta: La Paz: 2406993. Cochabamba: 4589455. Santa Cruz:
3343199. www.mintrabajo.gov.bo
Observaciones: Los Empleadores y Empresas constituidas e inscritas en el
Ministerio de Trabajo, podrán proceder a su reinscripción
con la sola presentación de la Resolución de Inscripción y el
llenado del Formulario Único de Registro de Empleadores
(El trámite de reinscripción será gratuito). El plazo de
tramitación en el Registro de Empleadores para empresas de

P á g i n a | 123
nueva constitución es de tres meses a partir del momento
que cuente con trabajadores. En caso de incumplimiento los
Empleadores, Empresas e Instituciones que operan en el
país, serán pasibles al pago de Multas y Sanciones
establecidas.
5.3.6 Derechos de autor a cumplir
Requisitos para el Registro de Software, Videojuegos, Página WEB y Social Media.
1. Carta de Solicitud de Registro dirigida a la Dirección de Derechos de Autor y Derechos
Conexos.
2. Fotocopia de la Cédula de Identidad del o de los Solicitantes, Autores y Titulares.
3. Formulario debidamente llenado, impreso y firmado.
4. El original y una fotocopia simple de los comprobantes de Depósito Bancario.
5. Una copia ejecutable del programa de computación.
6. Capturas de las pantallas y/o Video demostrativo.
7. Documentación adicional, manuales u otros similares.

P á g i n a | 124
Ilustración 11 Senapi 1
Ilustración 12 Senapi 2
P á g i n a | 125
P á g i n a | 126
CAPÍTULO VI:
INFRAESTRUCTURA PARA EL
DESARROLLO DEL SOFTWARE
P á g i n a | 127
Capítulo 6: Infraestructura para el desarrollo del Software
6.1 Gestión de la configuración del Software
6.1.1 Propósito
El propósito de este documento es presentar la descripción de hardware y software
para cada uno de los ambientes (desarrollo, pruebas y producción) necesarios para el
desarrollo del Sistema de Información.
6.1.2 Alcance
Realizar la descripción de los ambientes, listando cada uno de los elementos que los
conforman, pero sin incluir explicaciones sobre las decisiones de diseño y arquitectura que
se han tomado, ya que esta información se encuentra en el documento de arquitectura SAD.
La información de los ambientes de pruebas y producción corresponde a datos
suministrados por el área técnica de la Procuraduría General de la Nación, porque relaciona
la infraestructura configurada en el centro de datos de la misma.
6.2 Ambientes Establecidos
Los ambientes establecidos para el desarrollo del sistema son 3:
 Ambiente de desarrollo
 Ambiente de pruebas
 Ambiente de producción
6.2.1 Ambiente de desarrollo
6.2.1.1 Generalidades
El objetivo del ambiente de desarrollo es proveer la infraestructura de hardware y
software necesaria para realizar la implementación del sistema y la ejecución de pruebas

P á g i n a | 128
unitarias por parte de cada desarrollador. El ambiente de desarrollo cuenta con la siguiente
infraestructura de máquinas:
 Servidor
 GitHub
 Docker
A continuación, se presenta la descripción de cada uno.
5.2.2.2 Descripción
Servidor
Característica Descripción
Sistema Operativo Windows 10 Pro
Procesador Intel I5 6500
Memoria RAM Total 8GB
Disco Duro 1120GB
Dirección IP 35.184.50.217
Nombre Completo Sergio Driss Melendez
Ports http/https 80 43
Servicios configurados
P á g i n a | 129
6.2.2 Ambiente de pruebas
El objetivo del ambiente de pruebas es proveer la infraestructura de hardware y
software necesaria para realizar la ejecución de pruebas de integración, sistema y
funcionales para determinar el comportamiento de la aplicación en escenarios reales. Es
recomendable que este ambiente sea muy similar al ambiente de producción que permita
obtener resultados más acertados a la realidad. Es necesario que este ambiente tenga
configurado direcciones IP públicas para acceder al portal, al servidor de aplicaciones y al
servidor de reportes, así como visibilidad con los servidores relacionados.
El ambiente de pruebas cuenta con la siguiente infraestructura de servidores se utiliza
servidor de GitHub para la integración continua.
5.2.2.2.1 Multiplataforma: puede ejecutar construyo en Unix, Windows, OS X, y cualquier
otra plataforma que soporte Go.
5.2.2.2.2 Estable: tus construcciones ejecutarse en una máquina diferente a
GitHub.
5.2.2.2.3 Compilaciones paralelas: escisiones GitHub CI se basa en varios equipos, para una
rápida ejecución.
5.2.2.2.4 El registró en tiempo real: un eslabón de la petición de fusión le lleva al registro de
generación actual que se actualiza automáticamente.
5.2.2.2.5 Versionadas pruebas: un archivo. GitHub-ci.yml que contiene sus pruebas, lo que
permite que todos contribuyan cambios y asegurar todas las ramas obtiene las
pruebas que necesita.
5.2.2.2.6 Pipeline: puede definir múltiples trabajos por etapas y puede desencadenar otras
construcciones.
P á g i n a | 130
5.2.2.2.7 Autoscaling: se puede girar automáticamente hacia arriba y abajo de VM para
asegurar que su construye se procesan inmediatamente y minimizar los costos.
5.2.2.2.8 Construir artefactos: puede cargar binarios y otros artefactos de construcción a
GitHub y navegar y descargarlos. Prueba a nivel local hay varios ejecutores y se
puede reproducir pruebas localmente.
5.2.2.2.9 Soporte acoplable: puede utilizar imágenes personalizadas de estibador, girar los
servicios como parte de las pruebas, la construcción de nuevas imágenes Docker,
incluso funcionar en Kubernetes.
6.2.3 Ambiente de producción
El objetivo del ambiente de producción es proveer la infraestructura de hardware y software
necesaria para realizar la operación final del sistema. Es necesario que este ambiente tenga
configurado direcciones IP públicas para acceder al portal, al servidor de aplicaciones y al
servidor de reportes, así como visibilidad con los servidores relacionados.
6.2.4 Herramientas para el control de versiones
Es importante tener en cuenta las herramientas de control de versiones ya que con ellas
podemos integrar múltiples versiones de un mismo proyecto sin alterar el proyecto original.
Esto tiene muchas ventajas ya que cada miembro del equipo de desarrollo de software podrá
integrar cambios o versiones de prueba antes de lanzar el proyector a producción final.
6.2.4.1 Git
Desarrollador
 Linus Torvalds
Propósito
P á g i n a | 131
Originalmente fue diseñado como un motor de sistema de control de versiones de bajo nivel sobre el
cual otros podrían codificar interfaces frontales, tales como Cogito o StGIT.7 Desde ese entonces
hasta ahora el núcleo del proyecto Git se ha vuelto un sistema de control de versiones completo,
utilizable en forma directa.
Características
Fuerte apoyo al desarrollo no lineal, por ende rapidez en la gestión de ramas y mezclado de
diferentes versiones. Git incluye herramientas específicas para navegar y visualizar un historial de
desarrollo no lineal. Una presunción fundamental en Git, es que un cambio será fusionado mucho
más frecuentemente de lo que se escribe originalmente, conforme se pasa entre varios programadores
que lo revisan.
Gestión distribuida. Al igual que Darcs, BitKeeper, Mercurial, SVK, Bazaar y Monotone, Git le da a
cada programador una copia local del historial del desarrollo entero, y los cambios se propagan entre
los repositorios locales. Los cambios se importan como ramas adicionales y pueden ser fusionados
en la misma manera que se hace con la rama local.
Los almacenes de información pueden publicarse por HTTP, FTP, rsync o mediante un protocolo
nativo, ya sea a través de una conexión TCP/IP simple o a través de cifrado SSH. Git también puede
emular servidores CVS, lo que habilita el uso de clientes CVS preexistentes y módulos IDE para
CVS preexistentes en el acceso de repositorios Git.
Los repositorios Subversión y svk se pueden usar directamente con git-svn.
Gestión eficiente de proyectos grandes, dada la rapidez de gestión de diferencias entre archivos,
entre otras mejoras de optimización de velocidad de ejecución.
Todas las versiones previas a un cambio determinado, implican la notificación de un cambio
posterior en cualquiera de ellas a ese cambio (denominado autenticación criptográfica de historial).
Esto existía en Monótono.

P á g i n a | 132
6.2.5 Consideraciones generales
Es importante tener en cuenta las siguientes consideraciones para la configuración de
hardware y software de la infraestructura definida:
 Utilizar máquinas independientes entre el ambiente de pruebas y el ambiente de
producción. Si el sistema está operando en ambiente de producción, es necesario
tener un ambiente de pruebas donde se van probando las modificaciones que se
realizan al sistema antes de subir dichos ajustes al ambiente de producción, pero es
importante que su configuración sea muy similar para evitar resultados inesperados
en la operación final.
P á g i n a | 133
CAPÍTULO VII:
SITIO WEB DE LA EMPRESA
P á g i n a | 134
Capítulo 7: Sitio Web de la empresa
7.1 Desarrollo del Sitio Web
Ilustración 13 Página de la empresa
Dirección de enlace: http://www.conincosrl.com/

P á g i n a | 135
CAPÍTULO VIII:
ESTUDIO DEL MERCADO
P á g i n a | 136
Capítulo 8: Estudio del Mercado
8.1 Objetivo del estudio
Se tiene por meta la identificación de puntos favorables en el mercado para
consolidar una comercialización adecuadamente exitosa de un sistema de gestión de datos
web basado en un lenguaje interpretativo de script, para el adecuado manejo de sus datos a
usuarios que arrienden un hosting, para de esa forma aprovechar al máximo las
oportunidades.
8.2 Definición del producto
En la actualidad muchas empresas atraviesan por laboriosos procedimientos y
bastante papeleo para realizar las adquisiciones de nuevos productos en su inventario, es
por eso que con nuestro producto tenemos pensado librarnos de mucha perdida de tiempo
otorgando una salida directa a través del BlockChain.
8.3 Análisis de la demanda
8.3.1 Distribución geográfica del mercado de consumo
Geográficamente hablando la distribución del software es global, por la expansión de
lengua española y la gran cantidad de países hispano parlantes. Enfocando primeramente en
la ciudad de Santa Cruz junto con el resto de Bolivia, para su futura expansión a los demás
países latinoamericanos y finalmente hacia las partes de Europa donde exista un
significativo número de hispanoparlantes.
8.3.2 Proyección de la demanda
Tan solo en América se tiene una población actual aproximada de 1013 millones de
habitantes dividida entre sus 35 países (año 2019).

P á g i n a | 137
Tomando en cuenta solamente que el 10% cuenten con todas las características que
buscamos, tenemos un total de 101 millones de posibles usuarios:
SITIOS
CANTIDAD DE
HISPANOPARLANTES 1013 MILLONES
PORCENTAJE CON
CARACTERISTICAS 10%
SOLICITADAS
CATIDAD DE CLIENTES
POTENCIALES + - 101 MILLONES DE USUARIOS
8.4 Análisis de la oferta
8.4.1 Proyección de la oferta
El Software tiene como base fundamental las necesidades de la empresa Coninco, pero al ser
un software pensado en el futuro y la innovación, y con una línea de aprendizaje bastante corta, se
pretende asumir un plus a nuestro producto.
Nuestra propuesta busca agilizar el proceso para que los usuarios inviertan menos tiempo en
el uso.
8.4.2 Determinación de costo promedio
El software en estado base tendrá un costo de 700 dólares considerando todos los
gastos y esfuerzos realizados por el equipo de desarrollo, pero tendrá una siguiente fase en el
cual se trabajará como servicio, para poder gestionar el poceso de inventarios a otras
empresas
P á g i n a | 138
8.4.3 Canal de distribución
Como canal de distribución del producto se ha optado por un canal de distribución directo
ya sea mediante la adquisición directa del producto en la empresa o vía celular
descargándose la aplicación para el ciudadano desde el Play Store de su dispositivo móvil
con Android, el uso del internet, especialmente en los canales de negocios a negocios, va en
aumento, debido a que es un medio más directo y eficiente para comprar y vender
suministros y materias primas. Lo que nos llega a concluir que sería una aplicación muy
provechosa para toda la población de Santa Cruz de la Sierra.
8.4.4 Descripción de las decisiones tomadas
 Costos enfocados en necesidades posteriores para los usuarios y de poca relevancia
para el usuario común.
 Publicidad dentro de la aplicación para la generación de ingresos primarios para la
sustentabilidad.
 Promoción del producto por medio de anuncios en redes sociales
 Mantenimiento constante y mejora sin olvidar la filosofía de la compañía.

P á g i n a | 139
CAPÍTULO IX:
PRUEBAS EN EL SOFTWARE
P á g i n a | 140
Capítulo 9: Pruebas en el Software
9.1 Planificador de pruebas
 CU1. Gestionar Usuario
 CU2. Gestionar Privilegio
 CU3. Gestionar Personal
 CU4. Gestionar Cargo
 CU5. Gestionar Producto
 CU6. Gestionar Categoría
 CU7. Gestionar Proveedor
 CU8. Gestionar Sección
 CU9. Gestionar Almacén
 CU10. Gestionar Inventario
 CU11. Gestionar Reportes
9.2 Iteración en PUDS
 Planificación de la Iteración
 Captura de requisitos:
 Modelo de casos de uso, Modelo de Dominio, ...
 Análisis:
 Diagrama de secuencia del sistema, Contratos, Modelo Conceptual ...
 Diseño:
 Diagramas de interacción, Diagrama de Clases
 Implementación:
 codificación (Clases y métodos)

P á g i n a | 141
 Pruebas:
 verificación de la implementación
 Evaluación de la iteración
9.2.1 Caso de Prueba
Ilustración 14 Caso de Prueba
9.3 Diseñador de pruebas
CU Gestionar Usuario
 Entrada
Se Realizará el registro, modificación y eliminación de los datos de un usuario en general. Se
Deberá ingresar todos los datos necesarios de un usuario sin omitir siquiera el Código, todos estos
campos deberán ser rellanados de manera independiente
 Resultados
El Resultado óptimo que se espera es el que todos los datos sean registrados, Modificados o
eliminados en la Base de Datos sin excepción.
 Condiciones
Las condiciones en las que alguna de las acciones no podría realizarse variaran de acuerdo al
tipo de excepción que se genere, mases comúnmente por la búsqueda de códigos erróneos en el
sistema devolviendo valores nulos.

P á g i n a | 142
9.3.1 Procedimiento de Prueba
 Primeramente, se debe tener en cuenta que el código del rol o más específicamente el
código del usuario.
 Si cumple con las validaciones previas entonces si se verifica la acción que se va realizar y
de acuerdo a eso se podrán realizar acciones como:
 REGISTRAR
 MODIFICAR
 ELIMINAR
 Y así sucesivamente se podrá efectuar la verificación de un módulo del sistema y su
funcionalidad de acuerdo a ciertos parámetros ()
9.4 Método de la caja negra
Ilustración 15 Método de Caja Negra

Fuente: (pavjorge, 2015)
CU Gestionar Usuario
P á g i n a | 143
Entrada
 Código
 Correo Electrónico
 Contraseña
 Código Rol
Resultado
 Los datos del proceso son almacenados en la base de datos en la tabla Usuario.
 Retorna al formulario principal de Usuario.
 Se visualiza el nuevo Usuario en la lista de Usuarios.
Condiciones
 Las condiciones en las que alguna de las acciones no podría realizarse variaran de
acuerdo al tipo de excepción que se genere, comúnmente por la búsqueda de códigos
erróneos en el sistema devolviendo valores nulos.
9.4.1 Procedimiento de Prueba
 Presionamos el botón Nuevo para registrar el nuevo Usuario.
 El administrador llena los campos correspondientes.
 Presionamos el botón Guardar.
 La aplicación verifica que estén llenos los campos y registra al usuario, caso contrario
retorna un mensaje.
 Visualizamos el nuevo Usuario en la lista de Usuarios.
 Para modificar los datos de un Usuario presionamos el botón Editar, modificamos los
datos y luego presionamos el botón Guardar.
 Para eliminar un Usuario solo presionamos el botón Eliminar y se visualizara la nueva
lista de Usuarios.
P á g i n a | 144
CAPÍTULO X:
MARKETING
P á g i n a | 145
Capítulo 10: Marketing
10.1 Introducción
Para los pequeños negocios, Facebook puede ser el lugar perfecto para experimentar con
los anuncios pagados sin el riesgo de invertir mucho tiempo y dinero en una campaña de
publicidad. El gigante de las redes sociales ofrece una forma sencilla para que cualquier
empresa inicie rápidamente una campaña de anuncios en la que se muestre contenido del
negocio mientras los usuarios navegan en Facebook. Es posible crear anuncios para atraer
nuevos fans a una página, asegurar que los usuarios vean ciertos posts o, incluso, dirigir las
visitas a un sitio Web. Como ocurre con la mayoría de las campañas de pago por clic, los
negocios deben establecer un presupuesto que indique cuánto están dispuestos a pagar en
un periodo limitado. Los costos varían, pero en promedio cuestan menos de un dólar cada
uno, dependiendo de cuál sea tu audiencia. Las campañas en Facebook son más fáciles de
monitorear que las de pago por clic de los motores de búsqueda, debido a que requieren
mucho menos trabajo diario. También son más baratas que las de los medios tradicionales.
Y es que, hechos correctamente, los anuncios en Facebook pueden generarte muchos
nuevos fans a tu página y más visitas a tu sitio Web. Pero, lo más importante: pueden atraer
nuevos clientes.
10.2 Medios de propagación
Para iniciar, entra a tu Facebook y da clic al botón Crear un anuncio que se despliega en la
flecha descendente, justo a un lado de la pestaña “Inicio”. No necesitas tener una página de
fans para crear un anuncio, pero el dueño -o el encargado de la publicidad- sí debe tener
una cuenta personal (aunque los anuncios no se dirigen a los perfiles personales).
P á g i n a | 146
10.3 Decisiones de anuncios
En este punto, Facebook querrá saber a dónde deben dirigirse tus anuncios. Puedes enviar a
los usuarios a un sitio Web o al blog de tu empresa. También los puedes ligar a tu página de
fans o promover otras páginas tuyas en Facebook, como eventos y lugares.
10.4 Metas de publicidad
Una vez que elegiste a dónde debe dirigir tu anuncio, decide qué quieres hacer con él. Si
deseas construir mayor presencia de tu marca en redes sociales atrayendo fans a tu página
elige Conseguir más “Me gusta”. Si quieres promover contenido específico, de por ejemplo
tu blog, selecciona Promocionar publicaciones de la página. Si quieres atraer tráfico a tu
sitio Web, dale clic a Ver las opciones avanzadas.
Vale la pena experimentar con todas las opciones, aunque para esta demostración lo
haremos enfocándonos en anunciar un website.
10.5 Diseño de publicidad
Ahora es momento de diseñar. Los anuncios de Facebook consisten en encabezados de 25
caracteres y una descripción de 90 caracteres, más una fotografía. Facebook
automáticamente sugiere los textos, pero por lo general es mejor reescribirlo. Esto se puede
actualizar en tiempo real, por lo que no temas equivocarte.
El sitio despliega una imagen de 100x72 pixeles, por lo que debes asegurarte de usar una
foto que se vea clara en este formato. Facebook recomienda que tu imagen sea de este
tamaño, aunque el sitio hace el ajuste. Facebook posee numerosos estándares referentes a lo
que puedes y no publicar. Por eso, antes de hacer tu anuncio visita las Normas de
Publicidad.
P á g i n a | 147
10.6 Elección de público
Puedes delimitar a la audiencia de tu anuncio para que llegue sólo a ciertos usuarios. Los
puedes segmentar a ciertos códigos postales, después a edad, sexo e intereses. En las
opciones avanzadas puedes catalogar por idioma, lugar de trabajo, estado de relación o
simplemente conectar con tus fans.
10.7 Nombre, presupuesto y calendario
Ahora, es tiempo de nombrar tu campaña y de definir presupuesto y calendario. El nombre
es indistinto, pero te conviene elegir algo relacionado con la audiencia a la que se dirige.
Después, dile a Facebook cuánto dinero estás dispuesto a gastar; esto puede ser diario o
durante el tiempo que dure la campaña.
El pago puede ser por clic (cada que alguien le da clic a tu anuncio) o por número de
impresiones, es decir, cada vez que mil personas vean el anuncio. Puedes establecer
anuncios que se desplieguen continuamente o elegir horas exactas para que aparezcan.
10.8 Inversión de anuncios
Después de revisar tu primer anuncio, Facebook te pedirá la información de pago (tarjeta de
crédito, tarjeta de débito, PayPal o cupón de Facebook Ads). El cobro es mensual.
Facebook puede retener tu anuncio hasta por un día para aprobar el contenido.
10.9 Monitoreo de campaña
Ahora que tu campaña está corriendo, debes seguir su proceso usando la herramienta de
Administrador de anuncios, a la cual se accede desde el lado izquierdo de tu cuenta
personal. Ésta te muestra información de tus campañas, incluyendo tu presupuesto, gastos y
calendario. Dándole clic a una campaña de anuncios podrás entrar a observar más
información, incluyendo gráficas y métricas. Desde aquí puedes observar cuántas personas
P á g i n a | 148
han visto tu anuncio, cuántas veces se muestra en las actualizaciones y los números de
clics. Las dos métricas en las que debes enfocarte son los clics –lo que estás pagando- y las
acciones, que muestra cómo interactúa la gente con tus anuncios.
10.10 Generación de informes
Puedes exportar reportes desde la pestaña Informes en el Administrador de anuncios. Éstos
consisten en hojas de cálculo o archivos HTML que se pueden usar para comparar
anuncios. Esta función provee información que le ofrece al negocio una visión de su
campaña, incluyendo datos demográficos de las personas que le dan clic a los anuncios y la
cantidad de tiempo que tarda un usuario en darle “Me gusta” a una página.
10.11 Generación de informes
Si un anuncio no está logrando buenos resultados, cambia sus atributos seleccionando la
campaña a la que pertenece y luego dando clic en el anuncio en específico. Puedes editar el
texto, aumentar o disminuir la puja y ajustar tu audiencia.

P á g i n a | 149
CAPÍTULO XI:
ASPECTOS PARA LA PUESTA EN
MARCHA
P á g i n a | 150
Capítulo 11: Aspectos para la puesta en marcha
11.1 Firebase
Es una plataforma en la nube para el desarrollo de aplicaciones web y móvil. Está disponible para
distintas plataformas (iOS, Android y web), con lo que es más rápido trabajar en el desarrollo.
Aunque fue creada en 2011 pasó a ser parte de Google en 2014, comenzando como una base de datos
en tiempo real. Sin embargo, se añadieron más y más funciones que, en parte, permitieron agrupar los
SDK de productos de Google con distintos fines, facilitando su uso.
Ilustración 16 Firebase
Funciones de Firebase
Firebase dispone de diferentes funcionalidades, que se pueden dividir básicamente en 3 grupos:
Desarrollo (Develop), Crecimiento (Grow) y Monetización (Earn), a los que hay que sumar la
Analítica (Analytics).
DESARROLLO
El primer grupo de funciones es conocido como Desarrollo o Develop en Firebase. Como su nombre
indica, incluye los servicios necesarios para el desarrollo de un proyecto de aplicación móvil o web.
Estos contribuyen a que el proceso sea más rápido, puesto que se dejan determinadas actividades a
mano de Firebase, mientras que otras permiten optimizar diversos aspectos para conseguir la calidad
deseada.
P á g i n a | 151
Realtime database
Una de las herramientas más destacadas y esenciales de Firebase son las bases de datos en tiempo
real. Estas se alojan en la nube, son No SQL y almacenan los datos como JSON. Permiten alojar y
disponer de los datos e información de la aplicación en tiempo real, manteniéndolos actualizados,
aunque el usuario no realice ninguna acción.
Firebase envía automáticamente eventos a las aplicaciones cuando los datos cambian, almacenando
los datos nuevos en el disco. Aunque no hubiera conexión por parte de un usuario, sus datos estarían
disponibles para el resto y los cambios realizados se sincronizarían una vez restablecida la conexión.
Autenticación de usuarios
La identificación de los usuarios de una app es necesaria en la mayoría de los casos si estos quieren
acceder a todas sus características.
Firebase ofrece un sistema de autenticación que permite tanto el registro propiamente dicho
(mediante email y contraseña) como el acceso utilizando perfiles de otras plataformas externas (por
ejemplo, de Facebook, Google o Twitter), una alternativa muy cómoda para usuarios reacios a
completar el proceso.
Así, este tipo de tareas se ven simplificadas, considerando también que desde aquí se gestionan los
accesos y se consigue una mayor seguridad y protección de los datos. Se debe mencionar que
Firebase puede guardar en la nube los datos de inicio de sesión con total seguridad, evitando que una
persona tenga que identificarse cada vez que abra la aplicación.
Almacenamiento en la nube
Firebase cuenta con un sistema de almacenamiento, donde los desarrolladores pueden guardar
los ficheros de sus aplicaciones (y vinculándolos con referencias a un árbol de ficheros para mejorar
P á g i n a | 152
el rendimiento de la app) y sincronizarlos. Al igual que la mayoría de herramientas de Firebase, es
personalizable mediante determinadas reglas.
Este almacenamiento es de gran ayuda para tratar archivos de los usuarios (por ejemplo, fotografías
que hayan subido), que se pueden servir de forma más rápida y fácil. También hace la descarga de
referencias a ficheros más segura.
Crash Reporting
Para mantener y mejorar la calidad de la app, hay que prestar especial atención a los fallos, por lo
que los seguimientos de errores (y también del rendimiento general de la app) son clave para poder
actuar y solucionarlos.
Por ello, Firebase ofrece Crash Reporting, que detecta y ayuda a solucionar los problemas de la app,
consiguiendo un informe de errores muy detallado (con datos como el dispositivo o la situación en la
que se da la excepción) y organizado, puesto que los agrupa por similitud y los clasifica por
gravedad.
Test Lab
El Laboratorio de pruebas permite testear la app en dispositivos Android virtuales basados en los
parámetros que configuremos. De esta forma, es mucho más sencillo detectar posibles errores antes
de lanzar la aplicación.
Remote Config.
La configuración remota sirve para modificar ciertas funciones, aspectos o incluso la apariencia de la
aplicación sin que sea necesario publicar una actualización de la misma. De esta forma, no se
requiere ningún tipo de acción por parte del usuario y se trata de cambios mucho más dinámicos.
Existen diversos parámetros que permiten personalizar al detalle estos cambios, considerando
factores como la ubicación o idioma del usuario, su dispositivo de acceso, etc.

P á g i n a | 153
Cloud Messaging
Su utilidad es el envío de notificaciones y mensajes a diversos usuarios en tiempo real y a través de
varias plataformas.
Hosting
Firebase también ofrece un servidor para alojar las apps de manera rápida y sencilla, esto es, un
hosting estático y seguro. Proporciona certificados de seguridad SSL y HTTP2 de forma automática
y gratuita para cada dominio, reafirmando la seguridad en la navegación. Funciona situándolas en
el CDN (Content Delivery Network) de Firebase, una red que recibe los archivos subidos y permite
entregar el contenido.
CRECIMIENTO
El segundo bloque está enfocado al proceso de crecimiento de la aplicación, que contempla tanto la
gestión de aquellos que ya son usuarios de la misma, como herramientas para la captación de nuevas
audiencias.
Notifications
Las notificaciones son parte esencial de muchas aplicaciones para informar al usuario de eventos,
que pueden ir desde un mensaje recibido hasta una información relevante según el tipo de usuario.
Con esta herramienta, se pueden diseñar y enviar las notificaciones push en el momento preciso, con
la posibilidad, además, de segmentarlas y personalizarlas (por ejemplo, en base al usuario, su idioma
o el tipo de dispositivo que utiliza).
Este servicio es gratuito, seguro y sin límites, pero además cuenta con la posibilidad de vinculación a
Analytics. Con ello, se pueden conseguir datos y estadísticas sobre las notificaciones enviadas y
extraer conclusiones de gran valor.

P á g i n a | 154
App Indexing
App Indexing posibilita la integración de la aplicación en los resultados arrojados por el buscador de
Google, con el cual está vinculado Firebase. De este modo, las búsquedas sobre contenido
relacionado pueden mostrar la app indexada como resultado, impulsando el tráfico orgánico y dando
a conocer el proyecto.
Si quien accede a este resultado ya ha instalado la aplicación, esta se podría abrir para mostrarle
directamente el contenido que desee. De no haber descargado la app, se podría sugerir al usuario la
instalación.
Dynamic Links
Se trata de links “inteligentes”, que permiten redirigir al usuario a zonas o contenidos concretos de la
aplicación en función del objetivo que se quiera conseguir y de la personalización que se otorgue
a diversos parámetros de esta URL. Así, el funcionamiento de estos enlaces se dirige como queramos
y procurando una experiencia agradable para el usuario en diversas plataformas.
Son de especial utilidad para dirigir contenidos a ciertos segmentos de usuarios, ya sean actuales o
potenciales, en cuyo caso podrán recibir una recomendación de instalar nuestra app.
Invites
Mediante Invites, los usuarios tienen la posibilidad de invitar a sus contactos a utilizar la app o de
compartir contenidos específicos con ellos. Esto se realiza por diferentes medios, como e-mails o
SMS. Es interesante la posibilidad de cuantificar las invitaciones enviadas y la repercusión de las
mismas.
Adwords
Con AdWords y la posibilidad de realizar campañas de publicidad online, es más sencillo dar a
conocer la aplicación, impactando a usuarios potenciales para activar el crecimiento.

P á g i n a | 155
MONETIZACIÓN
La monetización en Firebase es la tercera pata contemplada. En este caso, la búsqueda de ganancias
viene ligada a la publicidad que se puede insertar en las aplicaciones, consiguiendo que los usuarios
de las mismas reciban anuncios relevantes en función de la segmentación que se le haya dado a la
campaña.
Para integrar estos anuncios en la app, Firebase cuenta con AdMob, muy interesante para rentabilizar
la aplicación.
ANALÍTICA
El análisis de datos y resultados es clave para la toma de decisiones coherentes y fundamentadas para
el proyecto y la estrategia de marketing asociada. Con Firebase Analytics, puedes controlar diversos
parámetros y obtener mediciones variadas desde un mismo panel de manera gratuita. Es compatible
con iOS, Android, C++ y Unity y, entre otras funciones, permite:
 Obtener mediciones y análisis de los eventos que tienen lugar en la aplicación. Se reciben
informes ilimitados con hasta 25 atributos.
 Comprobar el rendimiento de eventos, notificaciones y campañas publicitarias en redes,
basándose en el comportamiento de lo usuarios.
11.2 Políticas de Privacidad de Nuestra Aplicación
11.2.1.- Introducción
Es un documento legal por medio del cual la empresa informa a sus usuarios sobre la forma en la que
recabará los datos personales, describe cuál será el tratamiento de los datos y, en su caso, solicita el
consentimiento para la cesión de dichos datos a terceros.
El objetivo de este documento legal es ofrecer garantía jurídica y confiabilidad de las visitas o
usuarios hacia nuestra empresa, en lo que se refiere al tratamiento de sus datos de carácter personal.
P á g i n a | 156
Los datos a los que tienen acceso la mayoría de las aplicaciones móviles son nuestros contactos de la
agenda, fotos y datos de localización. Por ello, deben informarnos de la manera en la que van a
tratarse esos datos.
11.2.2.- Contenido
En la política de privacidad de una app debe incluirse la siguiente información:
 Finalidad de la recogida de los datos personales.
 Nombre y datos de contacto del responsable del tratamiento.
 Legitimación para el tratamiento de esos datos.
 Destinatarios de los datos.
 Periodo de conservación de dichos datos.
 Información a los interesados sobre el ejercicio de sus derechos y medio a través del cual
pueden ejercerlos.
 Pedir consentimiento específico para cada uno de los datos personales a los que la app va a
acceder.
 También debemos hacer referencia a los datos de menores y a servicios de localización.
11.2.3.- Modelo de Nuestra Política de Privacidad
POLÍTICA DE PRIVACIDAD PARA APLICACIONES MÓVILES (APPS)
Fecha última actualización: / /
De conformidad con el Reglamento (UE) 2016/679, del Parlamento Europeo y del Consejo, de 27 de
abril de 2016, relativo a

P á g i n a | 157
la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre
circulación de estos
datos (Reglamento General de Protección de Datos - RGPD), XXXEMPRESAXXX, informa a los
usuarios de la
aplicación _______________________ (en adelante, la Aplicación), acerca del tratamiento de los
datos personales, que ellos
voluntariamente hayan facilitado durante el proceso de registro, acceso y utilización del servicio.
1. IDENTIFICACIÓN DEL RESPONSABLE DEL TRATAMIENTO.
XXXEMPRESAXXX, con CIF/NIF nº: ________________ y domicilio a efectos de notificaciones
en:
________________________________________ e inscrita en el Registro Mercantil
de_________________ Tomo _________,
Folio ___________, Sección ª, Hoja _______, inscripción ª (en adelante, el responsable del
Tratamiento), es la entidad
responsable del tratamiento de los datos facilitados por los clientes de la Aplicación (en adelante,
el/los Usuario/s).
2. FINALIDAD DEL TRATAMIENTO DE DATOS.
Para proceder al registro, acceso y posterior uso de la Aplicación, el Usuario deberá facilitar -de forma
voluntaria-, datos de
P á g i n a | 158
carácter personal (esencialmente, identificativos y de contacto), los cuales serán incorporados a
soportes automatizados
titularidad de XXXEMPRESAXXX
La recogida, almacenamiento, modificación, estructuración y en su caso, eliminación, de los datos
proporcionados por los
Usuarios, constituirán operaciones de tratamiento llevadas a cabo por el responsable, con la finalidad
de garantizar el
correcto funcionamiento de la Aplicación, mantener la relación de prestación de servicios y/o
comercial con el Usuario, y
para la gestión, administración, información, prestación y mejora del servicio.
Los datos personales facilitados por el Usuario -especialmente, el correo electrónico o e-mail- podrán
emplearse también
para remitir boletines (newsletters), así como comunicaciones comerciales de promociones y/o
publicidad de la Aplicación,
siempre y cuando, el Usuario haya prestado previamente su consentimiento expreso para la recepción
de estas
comunicaciones vía electrónica.

P á g i n a | 159
3. LEGITIMACIÓN.
El tratamiento de los datos del Usuario, se realiza con las siguientes bases jurídicas que legitiman el
mismo:
• La solicitud de información y/o la contratación de los servicios de la Aplicación, cuyos términos y
condiciones se
pondrán a disposición del Usuario en todo caso, con carácter previo, para su expresa aceptación.
• El consentimiento libre, específico, informado e inequívoco del Usuario, poniendo a su disposición
la presente política
de privacidad, que deberá aceptar mediante una declaración o una clara acción afirmativa, como el
marcado de una
casilla dispuesta al efecto.
En caso de que el Usuario no facilite a XXXEMPRESAXXX sus datos, o lo haga de forma errónea o
incompleta, no será posible
proceder al uso de la Aplicación.
4. CONSERVACIÓN DE LOS DATOS PERSONALES.
Los datos personales proporcionados por el Usuario, se conservarán en los sistemas y bases de datos
del responsable del
Tratamiento, mientras aquél continúe haciendo uso de la Aplicación, y siempre que no solicite su
supresión.
P á g i n a | 160
Con el objetivo de depurar las posibles responsabilidades derivadas del tratamiento, los datos se
conservarán por un período
mínimo de cinco años.
5. DESTINATARIOS.
Los datos no se comunicarán a ningún tercero ajeno a XXXEMPRESAXXX, salvo obligación legal o
en cualquier caso, previa
solicitud del consentimiento del Usuario.
De otra parte, XXXEMPRESAXXX podrá dar acceso o transmitir los datos personales facilitados por
el Usuario, a terceros
proveedores de servicios, con los que haya suscrito acuerdos de encargo de tratamiento de datos, y que
únicamente accedan
a dicha información para prestar un servicio en favor y por cuenta del responsable.
6. RETENCIÓN DE DATOS.
XXXEMPRESAXXX, informa al Usuario de que, como prestador de servicio de alojamiento de datos
y en virtud de lo
establecido en la Ley 34/2002 de 11 de julio de Servicios de la Sociedad de la Información y de
Comercio Electrónico (LSSI),
retiene por un período máximo de 12 meses la información imprescindible para identificar el origen de
los datos alojados y el

P á g i n a | 161
momento en que se inició la prestación del servicio.
La retención de estos datos no afecta al secreto de las comunicaciones y sólo podrán ser utilizados en
el marco de una
investigación criminal o para la salvaguardia de la seguridad pública, poniéndose a disposición de los
jueces y/o tribunales o
del Ministerio que así los requiera.
La comunicación de datos a las Fuerzas y Cuerpos de Seguridad del Estado, se hará en virtud de lo
dispuesto por la normativa
sobre protección de datos personales, y bajo el máximo respeto a la misma.
7. PROTECCIÓN DE LA INFORMACIÓN ALOJADA.
El responsable del Tratamiento, adopta las medidas necesarias para garantizar la seguridad, integridad
y confidencialidad de
los datos conforme a lo dispuesto en el Reglamento (UE) 2016/679 del Parlamento Europeo y del
Consejo, de 27 de abril de
2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos
personales y a la libre
circulación de los mismos.
Si bien el responsable, realiza copias de seguridad de los contenidos alojados en sus servidores, sin
embargo, no se
P á g i n a | 162
responsabiliza de la pérdida o el borrado accidental de los datos por parte de los Usuarios. De igual
manera, no garantiza la
reposición total de los datos borrados por los Usuarios, ya que los citados datos podrían haber sido
suprimidos y/o
modificados durante el periodo de tiempo transcurrido desde la última copia de seguridad.
Los servicios facilitados o prestados a través de la Aplicación, excepto los servicios específicos de
backup, no incluyen la
reposición de los contenidos conservados en las copias de seguridad realizadas por el responsable del
Tratamiento, cuando
esta pérdida sea imputable al usuario; en este caso, se determinará una tarifa acorde a la complejidad y
volumen de la
recuperación, siempre previa aceptación del usuario. La reposición de datos borrados sólo está
incluida en el precio del
servicio cuando la pérdida del contenido sea debida a causas atribuibles al responsable.
8. EJERCICIO DE DERECHOS.
XXXEMPRESAXXX, informa al Usuario de que le asisten los derechos de acceso, rectificación,
limitación, supresión, oposición
y portabilidad, los cuales podrá ejercitar mediante petición dirigida al correo electrónico:
_____________________________
P á g i n a | 163
Asimismo, el Usuario tiene derecho a revocar el consentimiento inicialmente prestado, y a interponer
reclamaciones de
derechos frente a la Agencia Española de Protección de Datos (AEPD).
9. COMUNICACIONES COMERCIALES POR VÍA ELECTRÓNICA.
En aplicación de la LSSI (Ley de Servicios de la Sociedad de la Información), XXXEMPRESAXXX,
no enviará comunicaciones
publicitarias o promocionales por correo electrónico u otro medio de comunicación electrónica
equivalente que previamente
no hubieran sido solicitadas o expresamente autorizadas por los destinatarios de las mismas.
En el caso de usuarios con los que exista una relación contractual, jurídica o de servicios previa, el
responsable del
Tratamiento, sí está autorizado al envío de comunicaciones comerciales referentes a productos o
servicios del responsable
que sean similares a los que inicialmente fueron objeto de contratación con el cliente.
En caso de que el Usuario quiera darse de baja a la hora de recibir las citadas comunicaciones, podrá
hacerlo remitiendo su
voluntad por e-mail al correo electrónico: ____________________________________.

P á g i n a | 164
11.3 Infraestructura en Hardware
Los servidores que fueron requeridos en Amazon deberían de suministrar la capacidad
física requerida para el funcionamiento de los servicios y aplicaciones de una manera
rápida y fácil de añadir almacenamiento de archivos locales y de forma remota.
Los PC que fueron requeridos debían de suministrar la capacidad física requerida para el
funcionamiento de las aplicaciones del sistema Integrado, de una manera rápida.
Se implementó un equipo de Voz sobre IP, el MAX420 para llamadas al exterior, el que se
conectó directamente a la central telefónica. Como se puede apreciar en la Ilustración 18
Planteamiento de Empresa.
Ilustración 17 Infraestructura
P á g i n a | 165
11.4 Seguridad
Con el objetivo de brindar seguridad a la red Interna, filtrado de paquetes desde o hacia
Internet y protección de los servidores aplicaremos los siguientes:
Los servidores de Amazon fueron instalados dentro de una DMZ con el objetivo de
aislarlos de las estaciones de la red LAN y así controlar el acceso hacia los mismos.
Se ubicarán dos firewalls físicos Cisco Pix ASA 5505 uno para el control de paquetes
provenientes desde el ISP o carriers y otro para control de paquetes internos de la LAN, los
mismos que serán provistos por el carrier (Telconet). Como se puede apreciar lo anterior
mencionado en la Ilustración 19 Infraestructura de la Red.
Ilustración 18 Seguridad
11.5 Respaldos
La Empresa D&Q, como política de seguridad, decide implementar el respaldo de la
información de todos sus equipos informáticos, De la oficina matriz en la ciudad de Santa
Cruz, Por lo que decide la siguiente solución:
La compra de una Unidad de Almacenamiento que sea contenedora de toda la información
de su base de datos radicada en el Servidor principal.

P á g i n a | 166
Es así que se adquirieron Unidades de Cinta HP modelo Ultrium 448, basada en tecnología
LTO de segunda generación, que ofrece la mejor combinación de funciones y de valor para
proteger los datos de servidores SCSI y SAS de gama media. La Ultrium 448 ofrece una
capacidad de 400 GB comprimidos por cartucho de datos con soportes LTO 2, se reducirán
los costos informáticos y se incrementara la rentabilidad de la inversión. Con la capacidad
de realizar una copia de medio terabyte de almacenamiento en 2 horas y media, el
rendimiento rápido de la Ultrium 448 se ve mejorado por la función de adaptación de
velocidad de datos dinámica exclusiva de HP que permite adaptarse a la velocidad del host.
La Ultrium 448 ofrece compatibilidad de lectura y escritura con todos los soportes y
unidades Ultrium de primera y segunda generación.
11.6 Planes de contingencia
Los planes de contingencia son el instrumento de gestión para el manejo de las tecnologías
de información y las comunicaciones. Si bien es cierto se pueden presentar diferentes
niveles de daños, también se hace necesario presuponer que el daño ha sido total, con el fin
de tener un plan de contingencia lo más completo posible.
Por lo cual se hace necesario o indispensable contar con un plan de contingencias que
gestione el correcto funcionamiento de los servicios en el menor tiempo posible, ante
cualquier eventualidad. Es así que recomendamos a la empresa Expo Medios utilizar todas
las medidas técnicas elaboradas que incluye la siguiente subdivisión del de contingencia:
 Plan de Respaldo
 Plan de Emergencia
 Plan de recuperación
El plan de respaldo contempla las medidas preventivas antes de que se materialice una
amenaza.
P á g i n a | 167
Su finalidad es evitar dicha materialización a través de las siguientes políticas de respaldo:
Todos los empleados deben realizar copias mensualmente de su información en el Cd
suministrado.
El ingeniero responsable de Tecnología de Información debe tener respaldo del software
base en las unidades de almacenamiento externo de la empresa.
La empresa debe contar con un centro de respaldo (CP), ya sea propietario o arrendatario.
El plan de Emergencia contempla las medidas necesarias durante la materialización de una
amenaza, o inmediatamente después. Su finalidad es contrarrestar los aspectos adversos de
la misma.
Este protocolo debe incluir la participación y actividades a realizar en el plan de
emergencias determinando las funciones criticas como son: conectividad, acceso a internet,
correo electrónico, u otras aplicaciones mayores, como es el sistema integrado de base de
Datos.
P á g i n a | 168
CAPÍTULO XII:
VERSIÓN OPERATIVA DEL
SOFTWARE
P á g i n a | 169
Capítulo 12: Versión Operativa del Software
12.1 Software terminado de acuerdo a los factores de calidad
Seguridad
 Encriptado de contraseñas en la base de datos
 Garantizar la confiabilidad y el desempeño del sistema realizando validaciones
tanto en el cliente como en el servidor.
Fiabilidad
 El software deberá tener una interfaz clara y sencilla
Disponibilidad
 La disponibilidad del software deberá estar disponible las 24 horas del día,
garantizando la información que requiera el usuario en su momento
Mantenibilidad
 Deberá disponer de una documentación sobre las operaciones que realiza el
software para que cualquier encargado pueda realizar el mantenimiento con el
mínimo esfuerzo.
 El software deberá estar basado en un estándar de programación.
Portabilidad
 La aplicación móvil estará disponible en la App Store
Eficiencia
 La aplicación móvil dará una respuesta en menos de 5 segundos

P á g i n a | 170
Facilidad de Uso
 La aplicación móvil cuenta con una interfaz de fácil uso.

Proyecto Final Software 2

Cargado por

Información del documento

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

Proyecto Final Software 2

Cargado por

Copyright:

Formatos disponibles

Página |1

UNIVERSIDAD AUTONOMA GABRIEL RENE MORENO

FACULTAD DE INGENIERIA EN CIENCIAS DE LA COMPUTACION Y

“APLICACIÓN MÓVIL DE ABASTECIMIENTO DE

 MELENDEZ MARTINEZ SERGIO DRISS 215049187

SIGLA: INF 512 - SB

Capítulo 1: Plan de Administración del Proyecto.................................................................11

2.4.2.4 Sprint Retrospective.........................................................................................................33

Capítulo 10: Marketing.......................................................................................................143

ILUSTRACIÓN 1 MODELO DE CONTEXTO GENERAL................................................................................................................26

Capítulo 1: Plan de Administración del Proyecto

relación entre el vendedor y el consumidor.

A través de investigaciones, se logró conseguir una información necesaria de todo el procedimiento

1.2.1 Objetivo general.

Desarrollar una aplicación móvil de abastecimiento de inventarios mediante el uso de Smart

Contracts para la empresa Coninco SRL.

1.2.2 Objetivos específicos.

 Recopilar información del proceso de abastecimiento de inventarios que se realizan en

 Realizar la captura de requerimientos funcionales y no funcionales de la aplicación,

 Desarrollar interfaces de software intuitivas para los usuarios.

 Realizar pruebas con el objetivo de encontrar errores.

En esta aplicación se desarrollarán varias tareas en el registro físico de inventarios dirigidas a

la empresa Coninco SRL.

1.3.1 Módulo Usuario

asignado y el tipo de rol dentro del sistema que manejarán.

1.3.2 Módulo Producto

1.3.3 Módulo Inventario

En el módulo de inventario, se especificará la forma de registro de los productos dentro de nuestro

reportes sobre nuestros productos disponibles.

1.4 Fundamentación Teórica

1.4.1 Metodología Ágil

1.4.1.1 Propósito de SCRUM

tradicionales de desarrollo de software.

de alcanzar el objetivo deseado), comunicación y en la reducción de elementos intermedios,

incremental basada en iteraciones y revisiones.

1.4.1.2 Equipo de SCRUM

 El dueño del producto (Product Owner)

El Product Owner es el encargado de optimizar y maximizar el valor del producto, siendo la

Tradicionalmente, se ha entendido la labor del Product Owner como un gestor de requisitos o un

 El Equipo e desarrollo (Development Team)

desarrollar el producto, autoorganizándose y autogestionándose para conseguir entregar un incremento

de software al final del ciclo de desarrollo.

Product Backlog seleccionados (Sprint Backlog) durante el Sprint Planning.

sprint final eliminando cualquier dificultad que puedan encontrar en el camino.

1.4.1.3 Ingeniería de Software Asistida por Computadoras

Las herramientas CASE (Computer Aided Software Engineering, Ingeniería de Software

Asistida por Computadora) son diversas aplicaciones informáticas o programas informáticos

destinadas a aumentar el balance en el desarrollo de software reduciendo el costo de las mismas en

términos de tiempo y de dinero.

de errores entre otras.

prototipos virtuales de los productos. La geometría de un producto es inicialmente elaborada en un

como: construcción civil, metalmecánica, turbomáquinas, aeroespacial, automovilística, aeronáutica,

productos tales como:

la fase de prototipo y fabricación;

 Reducción de costos, ya que la simulación es más barata que el desarrollo de prototipos;

 Permite realizar cambios en los proyectos rápidamente;

 Disminuye el tiempo empleado en el desarrollo de producto;

 Reduce la cantidad de prototipos de prueba y en ocasiones hasta los elimina;

 Ayuda en la verificación del producto en cuanto a funcionalidad, ensambles y diseño,

permitiendo la revalidación cada vez que sea necesario;

1.4.1.4 Ingeniería basada en Componentes

el mayor retorno sobre la inversión.

entender el origen de muchos problemas que se han presentado históricamente en la construcción de

del software moderno.