Piad-516 Material

Software y Prototipado
MATERIAL TÉCNICO
DE APOYO
TAREA N°01
Desarrollo de prototipo
Demografía del mercado

Es el modelo de identificación de audiencia basado en datos clave como edad, sexo,
estado civil, ingresos, raza, ocupación, nacionalidad o religión. Es uno de los
métodos más utilizados de segmentación de mercado para marcas y empresas.
La segmentación demográfica suele ser una de las primeras paradas cuando las
marcas y empresas comienzan a segmentar a sus usuarios. Esto se debe a que este
tipo de clasificación ofrece algunas de las estadísticas más comunes y fáciles de
interpretar.
 Ventajas de la segmentación demográfica
Los datos son fáciles de obtener

Los datos requeridos en una segmentación de mercado demográfica suelen
ser accesibles para el público o no son muy complicados de obtener. Estos
pueden estar disponibles en archivos nacionales, y también pueden
recopilarse a través de encuestas, entrevistas y formularios de contacto.
Datos fáciles de analizar

Una vez que obtienes la información otorgada por una segmentación
demográfica, su análisis es bastante sencillo. Incluso, existen herramientas
gratuitas y de pago que recopilan y orientan dicha información para agilizar tu
proceso y aplicar tus resultados de forma inmediata en tus estrategias de
marketing.
Ayuda a desarrollar presencia en el mercado

Si de algo podemos estar seguros es que la segmentación demográfica
consiste prácticamente en un tipo de categorización obligatorio para que las
empresas empiecen a desarrollar su presencia en el mercado. Si no sabes
quién es tu cliente, poco podrás avanzar en cuanto a sus necesidades y
preferencias más específicas.
Mejora tus productos y servicios

Cuando tienes una comprensión profunda de tu público objetivo, puedes
ponerte en su lugar para satisfacerlo. Esto te lleva a tener relaciones leales
con tus clientes y los alientas a ver tus productos o servicios de una manera
más útil o cercana a lo que ellos prefieren o necesitan.
2
Optimiza tus estrategias de marketing

Una segmentación demográfica te permite ser mucho más específico con tus
estrategias de marketing; aclara tu visión, puedes tener más dirección en tus
planes de publicidad futuros y optimizar tus recursos, tiempo y presupuesto.
Inclusive, realizar una segmentación demográfica correcta también te permite

tener mayor visibilidad del recorrido de tus clientes y clientes potenciales.
 Desventajas de la segmentación demográfica
La información es muy básica

Si bien la segmentación demográfica suele ser un buen punto de partida, los
datos que brinda son muy básicos y solo indican quiénes son los clientes,
pero no se especifican sus hábitos de compra o motivaciones.
Aunque brinda información importante que debes conocer, lo cierto es que

también puede hacer declaraciones muy generales de los consumidores.
No ofrecen ventaja competitiva

Aunque los datos demográficos son capaces de decirte quiénes son tus
clientes, la información sigue siendo poco clara. Actualmente, existe una gran
variedad de sectores que buscan abrir su base de productos a una audiencia
más amplia, por lo que las empresas y marcas ya no pueden conformarse con
una categorización del tipo: «Juguetes para niñas», «Juguetes para niños».
Como ya lo mencionamos, este tipo de segmentación de mercado no te

determina qué atrajo a tus consumidores a tu categoría o producto, ni mucho
qué busca en este. Son una opción alternativa que no brinda ninguna ventaja
competitiva, pues no hay actitudes, necesidades, ni creencias que
aprovechar.
La información obtenida no es perdurable

Un consumidor, demográficamente hablando, no será el mismo hoy que en
diez años. Por ello, los datos recopilados por una empresa no podrán ser
usados durante tanto tiempo, pues la gente cambia en todos sentido: de
edad, dirección y estado civil, entre otros. Por ello, esta información debe
recopilarse constantemente para que el panorama no deje de ser realista.
Análisis de Procesos
Una organización que opera con una visión por procesos siempre necesita tener un
conocimiento profundo de cada flujo de trabajo. Al fin y al cabo, los procesos son
3
como las piezas de un engranaje, que deben funcionar bien tanto individualmente
como en conjunto.
El análisis de procesos te permite revisar y tener un amplio conocimiento de los

procesos empresariales, para comprobar cómo están funcionando con relación a:
 El objetivo: si está de acuerdo con las metas establecidas en la planificación

estratégica;
 Los recursos: si las tecnologías utilizadas y los recursos financieros y
humanos son acordes y están actualizados;
 Los costos y el tiempo: si hay formas de reducir costos y ganar tiempo en las
operaciones;
 El rendimiento: qué problemas tiene el equipo durante la ejecución;
 La calidad: las formas de mejorar la calidad de las entregas, entre otras.
 Para ello, se llevan a cabo entrevistas, recopilación de datos, simulaciones y
modelados, así como técnicas de análisis, como el FODA y el benchmarking.
¿Cuál es el objetivo del análisis de procesos?

La Gestión de Procesos de Negocio (BPM) es una disciplina de gestión
cíclica, es decir, se realiza en diferentes etapas, de forma secuencial y
continua.
Esto se debe a que los procesos deben mejorarse constantemente para que
generen más valor a la empresa y al cliente, además de que sufren
interferencias internas y externas todo el tiempo.
Entre las etapas del BPM se encuentra el análisis de los procesos de negocio.
Más que visualizar los procesos, se trata de una herramienta que permite
conocer el estado actual del proceso ("AS IS") y si está alcanzando los
objetivos estratégicos para los que fue determinado.
Al tener una visión completa es posible identificar los fallos y las

oportunidades de mejora y definir un rediseño del proceso, pasando al
siguiente paso.
¿Y cuáles son los beneficios de esto?

 A partir del análisis es posible:
Entender cómo está funcionando el proceso;
Supervisar y reajustar los objetivos estratégicos de la empresa;
Estandarizar las reglas del negocio y los flujos de trabajo;
Apoyar la toma de decisiones por parte de la dirección, según la información
4
obtenida en el análisis;
Conocer las entradas y salidas de los procesos;
Comprender las funciones dentro de cada proceso y quiénes son los
responsables de su gestión y ejecución;
Estipular indicadores de rendimiento (KPIs) para facilitar el seguimiento del
proceso;
Identificar los cuellos de botella y los traspasos y si es posible eliminarlos,
entre otros.
¿Cuándo hacer un análisis de procesos?

La mejora continua se consigue gracias a que los procesos se revisan,
analizan y mejoran constantemente. Por lo tanto, es importante que el análisis
del proceso se realice de forma regular.
Al fin y al cabo, las interferencias externas e internas se producen

continuamente y pueden perjudicar la planificación inicial y los ajustes de la
demanda. Pero, ¿cuáles son los procesos a partir de los que se debe
empezar el análisis? ¿Con qué frecuencia se debe revisarlos?
Según la guía BPM CBOK, se debe priorizar el análisis de procesos cuando:

 La organización actualiza su planificación estratégica para abordar los
estudios de mercado y los nuevos escenarios;
 Hay problemas de rendimiento en un proceso, como la mala calidad de un
producto o cuando el proceso no sigue las normas estipuladas;
 Las nuevas tecnologías surgen y se aplican para actualizar y automatizar
los procesos;
 Hay cambios estructurales en la empresa, como fusiones, adquisiciones y
escisiones;
 Surgen nuevas regulaciones externas, como nuevas leyes, crisis
económicas, medioambientales, políticas y otras.
¿Cómo hacer un análisis de procesos?
 El mapeo y el análisis de los procesos deben hacerse no sólo con

documentos gráficos ilustrativos, sino que deben servir de parámetro con
información concreta para ayudar a la toma de decisiones.
 Con este diagnóstico, los gestores podrán justificar futuras modificaciones

e inversiones en relación con los procesos actuales. Estos son los pasos
para realizar el análisis y la mejora de los procesos:
5
 Definir las prioridades: empieza por determinar cuáles son los procesos
más importantes que hay que analizar en este momento y cuál será el
orden del análisis. Para ello, la empresa debe enumerar los procesos
según su importancia y urgencia, en relación con su rendimiento, impacto
en la estrategia, rentabilidad, interacción con el cliente y otros aspectos.
 Entender el escenario: a continuación, es importante entender el entorno

en el que se inserta la empresa, como el escenario económico, los
intereses y el perfil de los clientes, las amenazas de los competidores,
entre otros.
 Establecer el alcance de los procesos que se incluirán en el análisis. Define

en qué medida se evaluarán y con qué profundidad.
 Definir el método: es necesario elegir el enfoque del análisis y la forma en

que se recogerán los datos.
 Definir el equipo: por último, establece las personas que se encargarán del
análisis y capacítalas. Dentro del equipo de análisis es posible establecer
al director del proyecto de análisis, al analista de procesos y a los
especialistas que aporten ideas a lo largo del trabajo.
 Definir el proceso AS IS: estudia el proceso tal y como funciona

actualmente y crea un modelo de esta versión.
 Especificar los puntos de mejora: después de definir el proceso tal y como

ocurre actualmente, es necesario verificar los puntos que son cuellos de
botella, traspasos, interacción con los clientes y actividades que añaden
más valor. Después de estas identificaciones será posible identificar los
puntos que pueden ser mejorados.
 Modelar el proceso TO BE: crear el modelo del proceso teniendo en cuenta

las mejoras que se definieron en el punto anterior.
Al realizar el análisis, recuerda documentar todo el proceso y evaluar las cuestiones

clave sobre los procesos, como las mejoras y los problemas relacionados:
 Costos y asignación de recursos

 Tiempo - Normalización y calidad
 Riesgos - Disposición del lugar de trabajo
 Cumplimiento legal
 Actores implicados y sus relaciones sociales
6
Figura 1: Beneficios del BPMS
La herramienta es capaz de centralizar en un mismo sistema toda la información

relacionada con los procesos, optimizar la recogida de datos, generar informes para
análisis, integrarse con otros sistemas de forma nativa –como CRM y ECM– y
también permitir el rediseño de los procesos en el propio software.
Análisis del Problema
El análisis de problemas es una de las cualidades básicas que todo desarrollador

debe poseer, reforzar y mejorar día a día. Las computadoras realizan tareas y
cumplen con los objetivos y funciones para las que han sido diseñadas.
Sin embargo ese diseño de las soluciones surge de la capacidad que un

desarrollador ha tenido para entender los procesos y componentes de un problema y
transformarlo en una solución programada.
La descripción de esos pasos que la computadora debe seguir desde el inicio hasta
el fin de la solución se conoce como algoritmo. Las computadoras están diseñadas
para ejecutar los algoritmos que los desarrolladores les programan.
Proceso para solucionar un problema
 Para solucionar un problema se sigue la metodología del pensamiento

computacional, por eso un acercamiento que se propone para buscar una
solución es la siguiente:
7
Figura 2: Pasos para solucionar un problema.
Definición del problema
 Los problemas que se pueden solucionar mediante un programa de

computadora deben estar bien definidos desde su origen, para ello es
esencial que tanto su situación inicial como la final estén claras.
 Aquellos problemas cuya solución sea abstracta, poco clara, confusa o

imposible, no clasifican como elegibles para ser resueltos por un programa
computacional.
 Por ejemplo: «eliminar la contaminación de los océanos», es un problema

donde su origen no está claro y su proceso para ser solucionado tampoco se
puede definir mediante pasos.
 Sin embargo, determinar el nivel de contaminación del agua en un país, si es

un problema que puede ser resuelto por un programa, ya que posee datos
que pueden ser procesados y evaluados para determinar una medición.
Conceptos básicos para el análisis
Antes de empezar a hablar sobre el análisis hay que tener claros los
siguientes conceptos:
 Datos de entrada: aquellos datos que hay que solicitarle al usuario

 Datos de salida: aquellos datos que hay que averiguar o que el programa
debe imprimir o retornar al usuario
 Datos establecidos o constantes: son aquellos datos para los que el
problema define su valor, o que son constantes como por ejemplo pi
8
 Datos intermedios: aquellos datos que el problema no indica pero que

surgen para apoyar la solución de un problema (por ejemplo al averiguar
un promedio se ocupa un dato intermedio que es la sumatoria de todos
los números)
Análisis
Antes de empezar a solucionar un problema, se debe analizar e identificar qué

información nos brinda el problema, qué información nos solicita averiguar y revisar
si hay constantes o valores establecidos.
El proceso de análisis debe realizarse siempre antes de empezar a escribir código, o

inclusive antes de realizar el algoritmo (diagrama de flujo).
Se recomienda seguir los siguientes pasos al analizar un problema.
1. Analizar, estudiar y comprender el problema para decidir si ocupamos

realizar alguna investigación adicional para entenderlo.
2. Identificar los valores de entrada.
3. Identificar qué nos solicita el problema averiguar (salidas).
4. Identificar si el problema nos da valores constantes o datos establecidos.
5. Identificar aquellos valores que el problema no nos indica, pero que se
requieren para encontrar la solución.
6. Especificar los procesos que se deben seguir para convertir los datos de
entrada en salidas del programa.
Ejemplo de análisis
Pablo tiene hambre por eso va al restaurante a comprar papitas y refrescos.

Sabiendo que las papitas cuestan 1000 colones y el refresco cuesta 800 colones,
debe averiguar cuánto le toca pagar a pablo si el impuesto de ventas es del 13% y
sabiendo que Pablo decide cuántas papitas y refrescos va a comprar.
Identificar entradas
Según el problema anterior se ocupan saber cuántas papitas y cuántos refrescos

desea comprar Pablo. Como el problema no indica la cantidad de ambos productos,
y al requerirse para lograr encontrar el resultado final, se da por supuesto que se le
deben pedir al usuario (Pablo).
9
Entradas
 Cantidad de papitas que Pablo desea comprar

 Cantidad de refrescos que Pablo quiere comprar
Identificar salidas
 Las salidas son aquellos datos que el problema nos pide averiguar, en este
caso es el monto que Pablo debe pagar por los productos que compró.
Salida
Monto a pagar
Identificar datos establecidos o constantes
Los datos establecidos son aquellos datos para los que el problema nos indica
específicamente su valor. En el problema tenemos tres valores establecidos.
Por otro lado no hay constantes que se puedan apreciar en el mismo.
 Datos establecidos o constantes

 Costo de las papitas : 1000
 Costo del refresco : 800
 Porcentaje del impuesto : 0.13 (en programación los porcentajes deben
convertirse en decimales ya que el operador aritmético % significa módulo)
Identificar los datos intermedios
Los datos intermedios son aquellos que el problema no menciona pero que son
esenciales para apoyar los procesos para llegar a la solución.
Por ejemplo al pensar en una factura de un restaurante, recordamos que

generalmente nos indican el monto subtotal de la compra que es la suma del costo
de los productos comprados.
El problema no nos indica que debemos averiguar el subtotal sin embargo sabemos
que los porcentajes de impuestos, descuentos, recargos, entre otros se suelen
realizar sobre los montos subtotales. Por lo tanto el subtotal se convierte en un dato
intermedio.
Sucede lo mismo con el monto del impuesto que depende del porcentaje. Por lo que
entonces para calcular el impuesto se debe realizar el siguiente proceso: impuesto =
porcentaje * subtotal.
10
 Datos intermedios
 subtotal
 impuesto
 Procesos a realizar
Figura 3: Identificar los datos intermedios.
Diseño
El diseño es la solución del problema, generalmente son la secuencia de pasos

(algoritmos) que deben ser programados en un lenguaje para que la computadora
los peuda seguir y ejecutar para dar una solución.
El diseño se puede representar de diferentes formas como el pseudocódigo o los

diagramas de flujo.
Implementación
Es el proceso mediante el cuál el diseño se transforma en un programa mediante un

lenguaje de programación que se adapte a las necesidades del problema.
Es importante recalcar que si el diseño está bien elaborado, la implementación

debería ser un proceso sencillo, el reto es adaptarse y entender la sintáxis del
lenguaje de programación escogido.
Pruebas
Lo único seguro que podemos tener al desarrollar programas es que éstos tienen
fallos, de mayor o menor gravedad o incluso algunos surgen ante ciertas
condiciones específicas.
Por esa razón las pruebas son necesarias para poder detectar aquellos posibles
fallos que sean más visibles y minimizar la posibilidad de que dichos fallos se
conviertan en errores al estar ejecutando y utilizando los programas.
11
Para probar se pueden seguir algunas técnicas como por ejemplo:
 Probar valores correctos

 Probar valores incorrectos
 Probar usar letras donde se esperaban números o viceversa (aplica igual para
otros tipos de datos)
 Colocar valores fuera de rango u opciones no permitidas
Identificación del ámbito
El ámbito del producto (o software) es el conjunto de funcionalidades y rasgos que

caracterizan el producto de software que deberá desarrollarse (SE Vocab, 2018). El
ámbito define lo que se considerará dentro del proyecto y lo que no será
desarrollado (Wiegers, 2003). Para definir el ámbito del software (Figura 4), se
recomienda considerar los siguientes aspectos (Pressman, 2005):
Contexto. Identificar el ambiente en el cuál operará el software por construir. Esto

implica determinar desde las plataformas de cómputo empleadas, contexto
organizacional y de negocios. Además, se deben considerar las restricciones que el
mismo contexto impone al software que se construirá.
Información. Se determinan los datos que son visibles a los usuarios y que se
producen como resultado de la operación del software. Además, se consideran la
gestión de datos de entrada.
Función y desempeño. Se determinan las funciones que deberá realizar el software
para que se transformen los datos de entrada en datos de salida. Además, se
determinan las características de calidad relevantes para el software que se
construirá.
Figura 4: Elementos por considerar en la definición del ámbito del producto.
12
El ámbito del producto debe ser comprensible tanto para los gestores del proyecto
como para los miembros del equipo técnico. Los requisitos de alto nivel que se
identifican con los distintos stakeholders pueden considerarse los rasgos (features)
que el software deberá proveer. Estos se deberán definir en términos cuantitativos
cuando sea necesario. En actividades subsiguientes del proyecto se pueden refinar
los requisitos técnicos del software.
El ámbito del proyecto, por su parte, considera como parte fundamental el ámbito del
producto. A partir de éste, define todas las actividades que deberán realizarse en el
proyecto para entregar al cliente un producto de software con las características
acordadas con el cliente.
Perfiles del ámbito
El concepto de perfil de usuario se emplea en el ámbito de la informática. Así se

denomina a un entorno personalizado para un individuo que se desarrolla de
acuerdo a sus preferencias de configuración.
De esta manera, cuando la persona inicia una sesión en un sistema con su perfil de
usuario, se cargan los valores ya establecidos. La información puede incluir desde
cuestiones visuales o estéticas (como una imagen de fondo o ciertos íconos, por
mencionar dos posibilidades) hasta detalles sobre las conexiones de red, los
programas (software) a usar, los accesos directos, etc.
El uso de perfiles de usuario en un sistema operativo, por ejemplo, brinda varias

ventajas. Con diferentes perfiles de usuarios, distintos sujetos pueden usar un
mismo equipo, manteniendo cada uno su propia configuración.
Los cambios que realiza un usuario, en este marco, no afectan las preferencias
fijadas por los demás. Esto quiere decir que cada usuario, al iniciar sesión con su
propio perfil, se encuentra con las condiciones que tenía cuando cerró su sesión
anterior, independientemente de lo hecho por las otras personas.
Una de las ventajas que ofrece la creación de diferentes perfiles de usuario en un

sistema operativo es la protección de los menores frente al contenido creado para
personas adultas. Ya sea que estemos hablando de películas, fotografías, canciones
o videojuegos con imágenes o texto que haga referencia a la violencia o al sexo
explícito, entre otras posibilidades, es importante que los más pequeños no se
expongan a estos temas porque no están preparados para entenderlos.
13
En el caso de las consolas de videojuegos, en la actualidad es posible crear varios

perfiles de usuario en cada dispositivo, gracias a lo cual cada uno puede
personalizar su experiencia, los padres puedes bloquear ciertos títulos para que sus
hijos no los utilicen y cada uno puede usar su propio dinero para comprar juegos sin
correr el riesgo de que los demás se lo quiten. Este último punto es útil en una casa
compartida, donde dos o más personas utilizan una misma consola pero no así un
mismo fondo de dinero.
Necesidades del ámbito y los usuarios
Generalmente hay dos tipos de requerimientos en el desarrollo de software y

aplicaciones: funcionales y no funcionales. Los requerimientos funcionales
especifican lo que debe hacer un sistema, mientras que los requerimientos no
funcionales especifican cómo debe comportarse el sistema.
 Requerimientos Funcionales
En general, los requerimientos funcionales describen acciones específicas

que el ingeniero de software debe ser capaz de realizar durante el desarrollo
de software. Los requerimientos funcionales a menudo se dividen en reglas
de negocio y casos de uso. Las reglas de negocio son declaraciones de alto
nivel que definen lo que un sistema debe hacer, mientras que los casos de
uso son descripciones más detalladas de cómo debe funcionar el sistema.
Algunos de los requerimientos más comunes en virtud de él incluyen:
 Las características y funcionalidad deseadas del producto

 Plataformas para desarrollar aplicaciones, por ejemplo, iOS, Android y
web
 Especificaciones de diseño en términos de tema, colores y fuentes
 Funcionalidad de back-end: integración APl y bases de datos
 Plazos de finalización
 Requerimientos no funcionales
Los requerimientos no funcionales describen características específicas que

el software debe poseer durante el desarrollo de la aplicación. Por lo general,
se dividen en tres categorías: rendimiento, seguridad y calidad.
14
 Requerimientos de rendimiento
Los requerimientos de rendimiento suelen dividirse en dos categorías: tiempo

de respuesta y rendimiento. El tiempo de respuesta es el tiempo que tarda un
sistema en responder a la solicitud de un usuario, mientras que el rendimiento
es el número de solicitudes que un sistema puede manejar. Son más críticos
para los sistemas interactivos, como las aplicaciones de escritorio y los sitios
web, donde los usuarios esperan respuestas inmediatas a sus acciones.
 Requerimientos de seguridad
Los requerimientos de seguridad especifican las medidas que un sistema

debe tomar para proteger los datos del acceso no autorizado. En algunos
casos, los requerimientos de seguridad también pueden especificar el nivel de
protección requerido, como confidencial o de alto secreto. Implica
autenticación, autorización y cifrado.
 Requerimientos de calidad
Especifica el nivel de calidad que debe cumplir un sistema. En algunos casos,

los requerimientos de calidad también pueden especificar los métodos
utilizados para medir la calidad, como la densidad de defectos o la
satisfacción del cliente. Los requerimientos de calidad son generalmente
cuatro medidas de calidad: conformidad, usabilidad, confiabilidad y
mantenibilidad.
Perspectiva general del sistema
Comprende los procesos necesarios para asegurar que el proyecto incluya todo el
trabajo requerido, y sólo el trabajo requerido. Encuentra la forma correcta de definir
el alcance en un proyecto de software desde el inicio para ahorrarte problemas
futuros.
En definitiva, si no está incluido en el alcance, no existe.
¿Pero exactamente creemos que debe tener una buena descripción de alcance
dentro de un proyecto de desarrollo de software?
Es esencial tener una buena identificación del trabajo necesario para entregar el
producto del proyecto. Además, se debe realizar la traducción de los objetivos a
15
entregables, que es aquello físico que el proyecto de desarrollo de apps, diseño web
o desarrollo de software en general, debe contener.
Un buen alcance, además, debe ser la base para desarrollar el cronograma, el

presupuesto app o presupuesto web y los recursos del proyecto. La definición de
estos es básica y en el alcance deben de aparecer.
Debe, por supuesto, incluir las actividades de gestión que se suceden dentro del
proyecto.
¿Quién participa en definición alcance proyecto software?

¿Quién participa en la elaboración del alcance? Debe participar el equipo del
proyecto y los interesados (stakeholders) que tengan ideas adicionales expresadas
en los puntos anteriores.
Un buen alcance es crítico para el éxito del proyecto. Y se construye sobre la base
de los principales entregables, riesgos, asunciones y restricciones documentadas en
el proceso de iniciación del proyecto.
Del alcance, se derivan tres documentos fundamentales en el desarrollo de software:
 Scope Statement
 WBS (Work Breakdown Structure – EDT)
 Diccionario del EDT (o WBS)
Una vez determinado el alcance, ya podemos proceder a realizar un presupuesto

app o un presupuesto web con la garantía que estará bien establecido el alcance del
proyecto
16
TAREA N°02
Análisis de Información
Requerimientos Funcionales del Sistema
Un requisito funcional define una función del sistema de software o sus

componentes. Una función es descrita como un conjunto de entradas,
comportamientos y salidas. Los requisitos funcionales pueden ser: cálculos, detalles
técnicos, manipulación de datos y otras funcionalidades específicas que se supone,
un sistema debe cumplir. Los requisitos de comportamiento para cada requisito
funcional se muestran en los casos de uso. Son complementados por los requisitos
no funcionales, que se enfocan en cambio en el diseño o la implementación.
Como se define en la ingeniería de requisitos, los requisitos funcionales establecen

los comportamientos del software.
Típicamente, un analista de requisitos genera requisitos funcionales después de

realizar los casos de uso. Sin embargo, esto puede tener excepciones, ya que el
desarrollo de software es un proceso iterativo y algunos requisitos son previos al
diseño de los casos de uso. Ambos elementos (casos de uso y requisitos) se
complementan en un proceso bidireccional.
Un requisito funcional típico contiene un nombre, un número de serie único y un

resumen. Esta información se utiliza para ayudar al lector a entender por qué el
requisito es necesario, y para seguir al mismo durante el desarrollo del producto.
El núcleo de los requisitos yace en la descripción del comportamiento requerido, que

debe ser clara y concisa. Este comportamiento puede provenir de reglas
organizacionales o del negocio, o ser descubiertas por interacción con usuarios,
inversores y otros expertos en la organización.
Requerimiento no Funcional calidad del Sistema
Atributos de calidad
Características, que al cumplirse, mejoran en gran medida la calidad del

software.
17
 Confiabilidad: Estos requerimientos plantean que las aplicaciones no son

perfectas pero limitan las fallas de la aplicación a determinados valores.
 Disponibilidad: Tiempo en que debe estar disponible la aplicación.
 Seguridad: Medidas de seguridad con relación a procedimientos que
impliquen el uso de información vulnerable como por ejemplo, las claves de
acceso al software.
 Mantenibilidad: Facilidad de reparar un defecto en el software.
 Portabilidad: El software debe funcionar en determinadas plataformas o bajo
ciertas condiciones.
Requerimiento no Funcional interfaces del Sistema
Interfaces externas
 El SW a veces debe interoperar con otras aplicaciones del cliente.
 Las interfaces pueden ser de hardware, software o de comunicaciones.
Interfaces de usuario
 El diseño de las interfaces de usuario a veces se considera como una tarea
en la fase de requerimientos.
 El diseño de interfaces en borrador (wireframes, mockups y prototipos)
sirven para que el cliente pueda expresar de una mejor manera lo que
quiere.
Reglas de Negocio
Las reglas de negocio guían la toma de decisiones diarias dentro de las empresas
trazando las relaciones entre los objetos, como los nombres de cliente y sus pedidos
correspondientes. Esta conversión de las actividades de negocio de una
organización en lógica empresarial concreta permite a los ingenieros de software y
analistas de negocio aplicar estas reglas en herramientas de flujos de trabajo u otras
aplicaciones para habilitar la automatización de procesos. Sin ellas, los procesos de
actualización pueden volverse más pesados y lentos, y los documentos están más
expuestos a error humano e inconsistencias. Una empresa que implementa reglas
de negocio puede ahorrar tiempo y dinero gracias a la optimización del trabajo y un
menor abandono.
Reglas de negocio frente a requisitos de negocio
Algunas personas pueden confundir los términos reglas de negocio y requisitos de

negocio, pero en realidad son muy distintos. Por ello, conviene señalar cómo se
utilizan dentro de los entornos empresariales.
18
Las reglas de negocio proporcionan la base para los sistemas de automatización:

recopilan información documentada o no documentada y la traducen en distintas
declaraciones condicionales. Por ejemplo, al realizar una orden de compra, el
proceso de aprobación puede diferir en función del coste. Es posible que las
herramientas y servicios que tengan un valor inferior a cinco mil dólares solo
necesiten aprobación del gestor, pero a medida que los costes se eleven, es posible
que requieran la aprobación de altos directivos. Las reglas de negocio formalizan
este proceso estableciendo umbrales bajo los cuales se envían las facturas a cargos
administrativos superiores, en lugar de a los gestores de primera línea. Las
declaraciones condicionales, como estas, se aplican en diversos procesos de
negocio.
Los requisitos de negocio establecen los criterios de éxito para un proyecto

determinado. Al especificar las tareas y los recursos necesarios para completar el
proyecto, los equipos pueden ver más claramente las carencias y las barreras que le
impiden lograr su objetivo. Este ejercicio suele completarse al inicio de un proyecto
de negocio para establecer las expectativas entre las partes implicadas y abordar
cualquier necesidad adicional para completar el proyecto.
Tipos de reglas de negocio
Las reglas de negocio se pueden clasificar de distintas formas, y pueden variar en su

clasificación en función de la fuente de información. Sin embargo,
independientemente de su categorización, las reglas de negocio suelen expresarse
mediante calificadores lógicos formales, tales como: "IF-THEN", "IF-ELSE", "ONLY
IF", "WHEN", etc. Esta sintaxis se utiliza en los siguientes tipos de reglas de negocio:
 Las reglas de restricción establecen condiciones que colocan restricciones a

las estructuras de objetos. Estas se puede dividir en tres subconjuntos
diferentes de reglas, que incluyen estímulo y respuesta, restricciones de
funcionamiento y restricciones de estructura. Las reglas de estímulo y
respuesta requieren que las condiciones sean verdaderas antes de que se
tome una acción, mientras que las reglas de restricción de funcionamiento
imponen restricciones antes y después de una operación determinada.
Finalmente, las reglas de restricción de estructura establecen políticas en
torno a las clases, los objetos y las relaciones entre ellos que no deben ser
desestimadas.
 Las reglas de derivación definen las condiciones bajo las cuales los hechos
pueden ser inferidos de otra información. Estas reglas se desglosan en dos
subconjuntos, que incluyen reglas de inferencia y reglas de cálculo. Las
reglas de inferencia especifican que si ciertos hechos son verdaderos, se
19
puede determinar una conclusión concreta, mientras que las reglas de cálculo
utilizan algoritmos para hacer estas inferencias.
 Este tipo de reglas son la base de los motores de reglas, que permiten a las
organizaciones automatizar las decisiones de negocio para acelerar diversos
procesos, como pedidos de clientes y envíos. Mejoran los procesos de
negocio porque proporcionan directrices sobre cuándo deben iniciarse,
detenerse o modificarse estos procesos para aplicar políticas de forma
coherente en todo el negocio.
Ejemplos de reglas de negocio
Las reglas de negocio se utilizan para diversos casos de uso, que pueden basarse
en restricciones internas o externas. De ellas, destacamos:
 Conformidad: las agencias reguladoras pueden aplicar reglas estrictas en una

serie de verticales, como finanzas, seguros, asistencia sanitaria y marketing.
Las reglas de negocio pueden ayudar a garantizar que cualquier documento
que sea revisado por cualquier organismo regulador cumpla con sus
requisitos correspondientes.
 Aprobación de solicitudes: mercados inmobiliarios y bancarios aprovechan las

reglas de negocio para procesar solicitudes de hipoteca o alquiler. Por
ejemplo, una organización puede rechazar a un aspirante si su puntuación de
crédito está por debajo de un umbral específico.
 Servicios de suscripción: las empresas pueden optimizar las reglas de

negocio para terminar sus servicios con un cliente específico si no reciben el
pago en un plazo establecido. Esto garantiza que la compañía no malgaste
recursos en un cliente que no está generando ingresos.
 Órdenes de compra y devoluciones: las reglas de negocio también se pueden

aplicar dentro del sector del comercio minorista. Por ejemplo, un negocio
puede rechazar la reclamación de devolución de un cliente para un producto
determinado si entra más tarde de una ventana de 30 días.
 Personalización: las herramientas de automatización de marketing permiten a

las empresas personalizar su sitio web en función de los atributos de los
visitantes. De esta manera, los especialistas en marketing pueden aprovechar
un conjunto de reglas de negocio para enviar un mensaje a diferentes
segmentos de audiencia. Por ejemplo, si usted es un visitante que regresa a
un sitio web, el negocio puede mostrarle fotos de la categoría de producto que
vio por última vez en su página de inicio, mientras que un nuevo visitante
puede recibir imágenes del producto más popular de la empresa.
20
Ventajas de las reglas de negocio
Las reglas de negocio pueden aportar una serie de ventajas a las organizaciones,
que optimizan las operaciones de negocio y, consecuentemente, reducen la
sobrecarga.
 Mayor eficiencia: programar las reglas de negocio para aplicaciones y flujos

de trabajo puede ahorrar tiempo a largo plazo. Cuando las reglas de negocio
deben actualizarse debido a cambios en las normativas o estándares de la
compañía, solo se debe actualizar este aspecto del programa, en lugar de
tener que realizar actualizaciones manuales en toda una aplicación de
software. Estas actualizaciones generalmente pueden ser manejadas por
recursos menos técnicos, como analistas de negocio, ahorrando recursos
técnicos para problemas más complejos.
 Mayor coherencia: las reglas de negocio garantizan que las tareas se

ejecuten de manera coherente, ya que se deben cumplir criterios específicos
para que una tarea determinada se ejecute. Por ejemplo, las agencias
reguladoras pueden requerir la terminación de algunos documentos. Las
empresas pueden crear plantillas personalizadas que no se marcarán como
completadas hasta que se hayan cumplido todos los campos obligatorios.
Como resultado, se producen menos errores humanos y si todas las reglas de
negocio se han implementado con precisión, los líderes pueden estar seguros
de que reúnen los requisitos de conformidad, evitando cargos y sanciones
innecesarias.
 Menos complejidad: la documentación de las reglas de negocio se puede

trasladar potencialmente a otras líneas de negocio, y los equipos pueden
reutilizar los documentos para otros flujos de trabajo, lo que reduce la
complejidad en toda la organización.
La minería de procesos y otros análisis de negocio pueden ayudar a

identificar las áreas donde se pueden aplicar las reglas de negocio en su
compañía para sacar el máximo partido de estas ventajas.
Limitaciones del Sistema
Algunas limitaciones en un proyecto de desarrollo de software podrían ser la

compatibilidad entre sistemas operativos, los recursos disponibles, el tiempo de
desarrollo y la integración con sistemas existentes.
21
Las restricciones en el contexto de un proceso de desarrollo de software se refiere a

las restricciones que limitan las opciones de diseño o implementaciones disponibles
al desarrollar.
Los SH nos pueden poner limitaciones relacionadas con su contexto de negocio,

limitaciones legales. También hay limitaciones técnicas relacionadas con
integraciones con otros sistemas.
El ciclo de vida del producto va a agregar limitaciones al producto, por ejemplo a

medida que avanza el proceso de implementación el modelo de datos va a ser más
difícil de modificar. El arquitecto debe balancear entre los requerimientos y las
restricciones.
Requerimientos de licenciamiento
Una licencia de software es un acuerdo legal entre el cliente final y el propietario del
mismo que establece los términos y condiciones para el uso de la herramienta. Esta
licencia de software puede incluir restricciones de uso, como el número de
dispositivos en los que se puede instalar, o limitaciones de tiempo, como la duración
de la licencia, por ejemplo.
En definitiva, es fundamental tanto para el propietario como para el comprador, ya

que establece los derechos y responsabilidades para ambas partes. Por eso, es
importante leer y entender la licencia de cada software antes de instalar y empezar a
utilizarlo. Solo así podremos asegurarnos de que se cumple lo establecido.
Tipos de licencias de software
Existen diferentes tipos de licencias de software, como las licencias de software de

pago, que requieren que el usuario pague una tarifa por su uso, y las licencias de
software libre y de código abierto, que permiten a los usuarios utilizar y modificar el
software de forma gratuita.
Veamos las distintas opciones más detalladamente:
 Licencia de Software de Pago
Como hemos comentado, con una licencia de software de pago el usuario

paga una tarifa para poder utilizarlo. Esta tarifa puede ser una compra única o
una suscripción que se renueva periódicamente.
22
Entre las ventajas de utilizar este tipo de licencia se encuentran:
 Soporte y actualizaciones: Suelen ofrecer soporte técnico y

actualizaciones regulares para el software, lo que garantiza que esté
actualizado y funcione correctamente.
 Funcionalidades avanzadas: Por lo general, incluyen funcionalidades
avanzadas que no se encuentran en las versiones gratuitas o de código
abierto del software.
 Garantía de calidad: Al pagar por una licencia de software, el usuario
puede esperar que el software sea de alta calidad y esté libre de errores.
Por otro lado, entre las ventajas se encuentran:
 Coste: El coste de la licencia puede ser prohibitivo para algunos usuarios,

especialmente si se trata de una suscripción anual.
 Restricciones de uso: Las licencias de software de pago suelen incluir
restricciones de uso, como el número de dispositivos en los que se puede
instalar.
 Dependencia del proveedor: El usuario depende del proveedor para
soporte técnico y actualizaciones, lo que puede ser una desventaja si el
proveedor no cumple con las expectativas del usuario.
 Licencias de software libre y de código abierto
Por otro lado, tenemos las licencias de software libre y de código abierto. Este
tipo de licencias permiten a los usuarios acceder al código fuente del
software, modificarlo y distribuirlo sin restricciones.
Aunque las licencias de software libre y de código abierto son dos conceptos
diferentes, a menudo suelen usarse forma intercambiable. En general, se
refieren a aquellas que permiten a los usuarios utilizar, modificar y distribuir el
software de forma gratuita.
Ventajas:
 Libertad para modificar el software: Los usuarios pueden modificar el

software para que se adapte a sus necesidades específicas, lo que puede
ser especialmente útil en el caso de empresas y organizaciones.
 Flexibilidad: Suelen ser muy flexibles y permiten a los usuarios utilizar el
software de la manera que mejor les convenga.
 Comunidad de usuarios: Suele tener una comunidad de usuarios activa y
colaborativa que trabaja en mejoras y actualizaciones del software.

23
Desventajas:
 Soporte técnico limitado: Aunque hay una comunidad activa de usuarios

que trabajan en mejoras y actualizaciones, puede haber una falta de
soporte técnico formal.
 Falta de funcionalidades avanzadas: En algunos casos, las versiones de
código abierto de software pueden carecer de funcionalidades avanzadas
que se encuentran en las versiones de pago.
 Complejidad: Su complejidad puede ser una desventaja para algunos
usuarios, especialmente para aquellos que no tienen experiencia en
programación o tecnología.
En este caso, es importante tener en cuenta que, a su vez, existen diversos

tipos de licencias de software y de código abierto, y cada una tiene sus
propias restricciones y requisitos. Las más comunes son las siguientes:
 LICENCIA MIT
En primer lugar, tenemos la licencia MIT. Esta licencia de código abierto
permisiva permite la reutilización y modificación del software con pocas
restricciones.
Fue desarrollada por el Instituto de Tecnología de Massachusetts (MIT) y

es una de las licencias de código abierto más populares.
Permite a los usuarios utilizar el software con fines comerciales y no

comerciales, modificarlo y distribuirlo sin restricciones. A diferencia de
otras licencias, la Licencia MIT no requiere que se publique el código
fuente modificado. Esto significa que los usuarios pueden modificar el
software y mantener el código fuente privado si lo desean.
Por otro lado, hay que tener en cuenta que la Licencia MIT también
incluye una exención de responsabilidad para los autores del software,
por lo que no son responsables de ningún daño que surja del uso del
mismo.
 LICENCIA GPL
En segundo lugar, la Licencia Pública General de GNU (GPL) es una
licencia de código abierto copyleft que requiere que todo el código fuente
de un programa esté disponible para cualquier persona que utilice el
software. También requiere que cualquier software derivado se publique
bajo la misma licencia. Esto significa que cualquier software que se
desarrolle a partir de un software con licencia GPL debe ser también de
código abierto y estar disponible para su distribución pública.
24
La GPL fue desarrollada por la Free Software Foundation (FSF) y es una

de las licencias de código abierto más populares. La GPL garantiza la
libertad de los usuarios para utilizar, copiar, modificar y distribuir el
software de acuerdo con sus propias necesidades y objetivos, siempre y
cuando se respeten los términos de la licencia.
 LICENCIA APACHE
También tenemos la Licencia Apache. Este es otro de los tipos de
licencias de software de código abierto que permite el uso, la modificación
y la distribución del software con pocas restricciones.
Fue desarrollada por la Apache Software Fundation y es una de las más

utilizadas en el mundo del software, ya que permite a los usuarios utilizar
la herramienta con fines comerciales y no comerciales, modificarla y
distribuirlas sin restricciones significativas.
A diferencia de otras, esta licencia incluye disposiciones sobre patentes

que proporcionan protección a los usuarios y desarrolladores de software
contra posibles demandas de patentes. Además, también permite a los
usuarios añadir sus propias condiciones y restricciones, siempre y cuando
no entren en conflicto con los términos de la licencia Apache.
 LICENCIA BSD
Por otro lado, la Licencia BSD es una licencia de código abierto permisiva
que permite la libre distribución, uso y modificación del software bajo
ciertas condiciones.
Fue desarrollada por la Universidad de California, Berkeley y es una de

las licencias de código abierto más antiguas.
La Licencia BSD permite a los usuarios utilizar el software con fines

comerciales y no comerciales, modificarlo y distribuirlo sin restricciones
significativas. A diferencia de otras licencias de código abierto, la Licencia
BSD no requiere que se publique el código fuente modificado. Sin
embargo, los usuarios deben proporcionar una copia de la licencia BSD y
la atribución del copyright en todas las copias del software.
 LICENCIA DE SOFTWARE PROPIETARIO

Por último, tenemos la Licencia de Software propietario. Esta licencia se
utiliza para software comercial que se distribuye bajo términos y
condiciones específicos. Se considera una propiedad exclusiva de la
empresa o persona que lo desarrolla y, por tanto, no está disponible
públicamente.
25
Los usuarios del software propietario solo tienen permiso para utilizarlo de
acuerdo con los términos de la licencia, lo que puede incluir limitaciones
en el número de usuarios, la duración del uso, la transferencia o la
modificación del software.
A diferencia del resto de licencias de código abierto, las licencias de

software propietario no proporcionan acceso al código fuente del software,
lo que significa que los usuarios no pueden ver cómo funciona el software
ni realizar modificaciones.
Estas licencias suelen ser costosas y se utilizan sobre todo para software
comercial de alto nivel o especializado que requiere un soporte técnico y
de actualizaciones a largo plazo.
Casos de uso
Objetivos empresariales
Una empresa ejecuta un trabajo que utiliza dos productos de software con
licencia. El producto SoftwareA se rige por un acuerdo de licencia de nodos
bloqueados para el que la empresa tiene cuatro derechos asignados a
SistemaA, SistemaB, SistemaC y SistemaD. Para el producto SoftwareB, la
empresa tiene una licencia flotante, para la que hay tres derechos disponibles
para todos los sistemas de la red. El trabajo se envía garantizando el
cumplimiento de las políticas de licencias.
Roles
En este apartado se enumeran los roles de usuario necesarios para ejecutar

el caso de ejemplo:
 Desarrollador de intermediario de carga de trabajo dinámico

 Define los trabajos con la Job Brokering Definition Console
 Operador de intermediario de carga de trabajo dinámico
 Supervisa y controla los trabajos enviados.
 Planificador de trabajos de IBM Workload Scheduler
 Gestiona la carga de trabajo de Tivoli Workload Scheduler enviando y
supervisando trabajos.
26
Requisitos de software
Antes de ejecutar este caso de ejemplo debe instalarse y configurarse el

software siguiente:
 Una red de IBM Workload Scheduler versión 8.5.1 con la capacidad de

planificación dinámica.
 De forma opcional, Dynamic Workload Console versión 8.5.1.
Configuración del entorno
Para ejecutar el caso de ejemplo debe instalar o actualizar a IBM Workload

Scheduler versión 8.5.1. Complete las tareas descritas en el apartado
Configuración del entorno para la planificación dinámica.
Ejecución del caso de ejemplo
Antes de empezar
Antes de crear el trabajo, el administrador utiliza la opción Tarea Definir un

nuevo recurso lógico de Dynamic Workload Console para crear los recursos
lógicos, tal como se muestra en el apartado Tabla 1. Cada uno de los
recursos lógicos de licencias no bloqueadas se asigna a un sistema, y las
cantidades especificadas sólo las pueden utilizar los trabajos que se ejecutan
en el sistema especificado. El recurso lógico de licencia flotante es un recurso
global. No se asigna a un sistema y se puede acceder a él mediante un
trabajo en ejecución en cualquier sistema hasta que se utilice la cantidad
total.
Figura 5: Recursos lógicos para controlar la disponibilidad de licencias.
27
Para crear una definición de trabajo que utilice estos recursos lógicos para
incluir requisitos de licencias, realice los pasos siguientes:
Procedimiento
1. En Job Brokering Definition Console, seleccione Archivo > Nuevo > Job
Brokering Definition y cree una nueva definición de trabajo denominada
jobThatConsumesLicenses. La definición de trabajo se abre en la
página Visión general con el nombre de trabajo asignado.
2. Abra la página Aplicación y defina la información necesaria para la

aplicación que va a ejecutar el trabajo.
3. Abra la página Recursos y seleccione la ficha Requisitos de software.
4. Cree un requisito para un recurso lógico de SoftwareA, del modo

siguiente:
 En el panel Recursos lógicos, pulse Añadir. Aparece el recuadro de
diálogo Detalles de recurso lógico.
 En el campo Tipo, escriba SoftwareA y pulse Aceptar . Aparecen los
detalles de Recurso lógico.
 En el área de detalles de Recurso lógico, especifique 1 en el campo
de cantidad.
5. Abra la página Recurso relacionado y cree un requisito para el recurso

lógico de SoftwareB, del modo siguiente:
 En el panel Requisitos de recursos, pulse Añadir. Aparece el

recuadro de diálogo Detalles de requisitos del recurso.
 En el campo ID, especifique un ID significativo, en este ejemplo,
licencia_global_flotante.
 En el campo Tipo, seleccione Recurso lógico y pulse Aceptar.
 En el panel Propiedades de recursos, pulse Agregar requisito.
Aparece el recuadro de diálogo Detalles de requisitos del recurso.
 Seleccione Subtipo en el menú Nombre de la propiedad, escriba
SoftwareB en el campo Valor de propiedad y pulse Aceptar.
 En el panel Asignaciones, pulse Añadir. Aparece el recuadro de
diálogo. Detalles de la asignación.
 Seleccione Cantidad en el menú Nombre de la propiedad, escriba 1
en el campo Cantidad y pulse Aceptar.
28
6. Seleccione Archivo > Guardar para guardar el archivo de definición de

trabajo.
7. Seleccione el nuevo JSDL y cárguelo en el servidor pulsando el icono

correspondiente
8. Envíe el procedimiento de trabajo de una de la maneras siguientes,

según si desea enviarlo como un trabajo intermediario o utilizando una
definición de trabajo de Tivoli Workload Scheduler.
 Inicie sesión en la Dynamic Workload Console y seleccione la opción

del menú de tareas de Tivoli Dynamic Workload Broker.
o Seleccione Definicione > Trabajos , especifique opcionalmente
criterios de búsqueda y pulse Buscar. Seleccione la definición de
trabajo que haya creado en los pasos anteriores.
o Para ejecutar la tarea, seleccione Enviar y pulse Continuar.
 Inicie sesión en la Dynamic Workload Console y seleccione la opción

del menú de tareas de Tivoli Workload Scheduler.
o Seleccione Carga de trabajo > Diseñar > Crear definiciones de

carga de trabajo. En el Workload Designer, cree una nueva
definición de trabajos de intermediario completando los campos
necesarios tal como corresponda. En el campo Nombre de
trabajo de Workload Broker, escriba el nombre del archivo JSDL
creado en los pasos comprendidos entre el 1 y el 7.
o Envíe el trabajo IBM Workload Scheduler seleccionando Carga
de trabajo > Enviar > Someter trabajos predefinidos.
También puede agregar el trabajo a una secuencia de trabajos
existente o enviar el trabajo utilizando el mandato jobsubmit.
Para obtener más información sobre la interfaz de la línea de
mandatos de Dynamic Workload Broker, consulte el apartado
IBM® Workload Scheduler: Planificación dinámica de la carga de
trabajo.
Resultados esperados
Cuando se envían los trabajos, éstos se reenvían a uno de los nodos con una
licencia de nodos bloqueados y utilizando una de las licencias globales
flotantes, según las políticas de licencia. Con los ajustes utilizados en este
caso de ejemplo, el número máximo de instancias de
jobthatConsumesLicenses que se pueden ejecutar a la vez es 3 porque cada
29
una de ellas tiene asignada una licencia flotante de SoftwareB. Las instancias
pueden ejecutarse en el mismo sistema o en sistemas diferentes que tengan
la licencia de nodos bloqueados de SoftwareA.
Archivo de configuración de ejemplo
El archivo JSDL creado para este caso de ejemplo tiene la sintaxis siguiente:
Figura 6: Archivo de configuración.
30
TAREA N°03
Definición de Arquitectura
Dominio de la arquitectura
El diseño basado en dominios (DDD) es un enfoque para el desarrollo de software

que enfatiza la comprensión del dominio o entorno comercial de un sistema de
software y traduce esa comprensión en un modelo que se puede usar para guiar el
diseño y desarrollo del sistema. Los principios de DDD guían a los arquitectos de
software al proporcionar un conjunto de pautas y prácticas para desarrollar software
que satisfaga las necesidades de la empresa y sus usuarios.
El domain es la parte que, por lo general, se suele llamar dominio. Es el encargado

de representar lo que se está simulando dentro del ordenador.
No obstante, ¿a qué nos referimos con esto? Cualquier programa que desarrollas,
normalmente, está simulando algo del mundo real. Por ejemplo, puede que estés
desarrollando una aplicación de bolsa y, por ende, necesitas simular el mercado, la
zona de compras y ventas o las opciones, entre otras cosas. A esto es a lo que
llamamos domain o dominio.
Los componentes del domain en un software más habituales son:
 Domain agents: son elementos de funcionalidad mínima que tienen una

responsabilidad única; digamos que son «cosas» que tienen una
contrapartida en el sistema que se está simulando. Por lo general, en los
lenguajes de programación se suelen conocer como clases o tipos; no
obstante, existen algunos libros que los llaman «entidades», lo cual da lugar a
confusión. En resumen, los domain agents hacen referencia a las «cosas»
que representan lo que se encuentra en el dominio.
 Repositorios: son el segundo de los componentes del domain en un software

y hacen referencia a interfaces para la creación de los domain agents. Los
repositorios se suelen usar para servir como barrera de abstracción para
ocultar detalles que, en el fondo, al dominio le traen sin cuidado.
 Domain controllers: son acciones que se van a llevar a cabo sobre algunos de
los agentes. Por tanto, lo que hacen es intermediar y controlarlos. Los domain
controllers pueden ser clases o funciones, todo depende de lo complejo que
se esté haciendo el programa.
31
En la siguiente imagen puedes ver una representación gráfica de cómo se

relacionan los componentes del domain en un software:
Figura 7: Componentes del domain en un software.
Alcance y Restricciones
El alcance de la arquitectura define los límites y las fronteras del sistema. Establece
qué funcionalidades y características se incluirán en el sistema y cuáles se excluyen.
Las restricciones son limitaciones impuestas por el entorno o los requisitos del
sistema. Pueden incluir restricciones de rendimiento, seguridad, compatibilidad o
tecnología.
Actores del sistema y escenarios clave
Los actores del sistema son las entidades externas que interactúan con el sistema.
Pueden ser usuarios finales, otros sistemas, dispositivos o servicios externos. Los
escenarios clave son situaciones o casos de uso específicos en los que los actores
interactúan con el sistema. Identificar los actores y los escenarios clave ayuda a
comprender los requisitos y las necesidades del sistema.
Metas de la Arquitectura
Las metas de la arquitectura son los objetivos que se pretenden lograr con el diseño
y la implementación del sistema. Pueden incluir metas relacionadas con el
rendimiento, la escalabilidad, la seguridad, la usabilidad o la modularidad. Las metas
de la arquitectura ayudan a guiar las decisiones de diseño y a evaluar el éxito del
sistema.
32
Requisitos Significativos de la Arquitectura
Los requisitos significativos de la arquitectura son aquellos requisitos que tienen un

impacto significativo en el diseño y la estructura del sistema. Pueden incluir
requisitos de rendimiento, requisitos de seguridad, requisitos de escalabilidad o
requisitos de integración con otros sistemas. Identificar y comprender estos
requisitos es fundamental para el diseño de una arquitectura efectiva.
Ventajas del Modelo Vista Controlador
El Modelo Vista Controlador (MVC) es un patrón de diseño de software que separa

la lógica de presentación de la lógica de negocio y los datos. Algunas ventajas del
uso de MVC son:
 Separación de responsabilidades: El MVC divide el sistema en tres

componentes principales (modelo, vista y controlador), lo que facilita la
gestión y el mantenimiento del código.
 Reutilización de código: Al separar la lógica de presentación de la lógica de
negocio, es más fácil reutilizar y probar cada componente de forma
independiente.
 Flexibilidad y escalabilidad: El MVC permite realizar cambios en la interfaz de
usuario sin afectar la lógica de negocio subyacente, lo que facilita la
adaptación y la evolución del sistema.
 Facilidad de mantenimiento: La separación de responsabilidades y la
modularidad del MVC hacen que sea más fácil realizar cambios y
correcciones en el sistema sin afectar otras partes del código.
En resumen, el MVC es un enfoque de diseño que promueve la modularidad, la

reutilización y la flexibilidad en el desarrollo de software.
33
TAREA N°04
Diseño del Prototipo
Modelo de Datos
Los modelos de datos son representaciones visuales de los elementos de datos de

una empresa y de las conexiones entre ellos. Ayudando a definir y estructurar los
datos en el contexto de los procesos empresariales correspondientes, los modelos
respaldan el desarrollo de sistemas de información eficaces. Permiten que los
recursos empresariales y técnicos decidan conjuntamente cómo se almacenarán,
compartirán, actualizarán y aprovecharán los datos en toda la empresa, cómo se
accederá a ellos.
¿Qué es un modelo de datos lógico?
Un modelo de datos lógico establece la estructura de los elementos de datos y las

relaciones entre ellos. Es independiente de la base de datos física que detalla cómo
se implementarán los datos. El modelo de datos lógico sirve como modelo para los
datos utilizados. El modelo de datos lógico lleva los elementos del modelado de
datos conceptuales un paso más allá al agregarles más información.
Figura 8: Modelo de datos lógico.
El modelo de datos lógico incorpora todos los elementos de información que son
vitales en el funcionamiento de las actividades comerciales diarias.
34
Componentes de un modelo de datos lógico
Un modelo de datos lógico tiene tres componentes principales:
 Entidades: cada entidad representa un conjunto de cosas, personas o

conceptos relevantes para una empresa.
 Relaciones: cada relación representa una asociación entre dos de las
entidades anteriores.
 Atributos: cada atributo es una pieza descriptiva, característica o cualquier
otra información que sea útil para describir más detalladamente una entidad.
Cada uno de estos componentes de un modelo de datos lógico recibe un
nombre y una definición textual. Estos sirven para documentar continuamente
las reglas comerciales y delinear los requisitos de información. Sin embargo,
los componentes anteriores se limitan únicamente a descripciones de
requisitos comerciales. No se relacionan con cómo se procesan, implementan
o almacenan dichos requisitos comerciales.
La necesidad de un modelo de datos lógico
Como los datos representan el aspecto más importante de cualquier aplicación,

programa o sistema, los sistemas de procesamiento y almacenamiento de datos de
calidad deben construirse sobre una estructura de datos subyacente sólida y
precisa. Una estructura de datos sólida brinda a los desarrolladores de aplicaciones
la libertad de diseñar la mejor interfaz de usuario, el sistema de procesamiento o la
configuración de informes y análisis estadísticos posibles.
No importa qué tan elegante o técnico sea su sistema, tiene que cumplir con los
requisitos, seguir las reglas y servir a los propósitos del negocio o la empresa para
los que se diseñó, de lo contrario no tiene ningún uso práctico. Por lo tanto, el
modelado de datos lógico reúne los dos elementos básicos más importantes del
desarrollo de aplicaciones:
 Requisitos comerciales
 Estructura de datos de calidad
Características de un modelo de datos lógico
 Estas son las características más importantes de un modelo de datos lógico:

 Un modelo de datos lógico puede describir las necesidades de datos para
cada proyecto individual. Sin embargo, está diseñado para integrarse a la
perfección con otros modelos de datos lógicos si el proyecto así lo exige.
35
 Un modelo de datos lógico se puede desarrollar y diseñar

independientemente del sistema de gestión de la base de datos. El tipo de
sistema de gestión de base de datos no lo afectará tanto.
 Los atributos de datos contienen tipos de datos con longitud y precisión
exactas.
 En el modelado de datos lógico, no se define ninguna clave principal o
secundaria. En este nivel de modelado de datos, es necesario verificar y
modificar los detalles del conector que se establecieron antes de definir
las relaciones.
 Un modelo de datos lógico es como una representación gráfica de los
requisitos de información de un área de negocio. No es una base de datos
o un sistema de gestión de bases de datos en sí mismo.
 Un modelo de datos lógico es independiente de cualquier dispositivo de
almacenamiento de datos físicos, como un sistema de archivos.
 Un modelo de datos lógico debe diseñarse para que sea independiente de
la tecnología, de modo que no se vea afectado por los rápidos cambios en
la tecnología.
La información del modelado de datos lógico
Un modelo de datos, en pocas palabras, es un conjunto de especificaciones de

datos y diagramas relacionados para explicar los requisitos de datos y los diseños
relacionados. En términos generales, hay tres tipos de tipos y actividades de
modelado de datos:
 Modelo de datos conceptuales

Este modelo de datos básicamente define lo que el sistema contiene
inherentemente. Las partes interesadas comerciales y los arquitectos de
datos suelen ser quienes crean modelos de datos conceptuales con la
intención de organizar y definir varios conceptos y reglas comerciales y
establecer los parámetros o el alcance de los mismos.
 Modelo de datos lógico

Un modelo de datos lógico sirve para definir cómo debe implementarse un
sistema, independientemente del sistema de gestión de bases de datos que
se utilice. Los arquitectos de datos y los analistas comerciales suelen ser los
creadores de un modelo de datos lógico. El objetivo de crear un modelo de
datos lógico es desarrollar un mapa altamente técnico de reglas subyacentes
y estructuras de datos.
36
 Modelo de datos físicos

El modelo de datos físicos se ocupa de cómo se implementará el sistema y
los factores en el sistema de gestión de bases de datos específico. Este
modelo normalmente lo crean los desarrolladores. La idea es más definir
cómo se usará o implementará la base de datos real para fines comerciales.
En términos generales, tanto el modelado de datos conceptuales como el modelado

de datos lógico son tipos de actividades de "análisis de requisitos", mientras que el
modelado de datos físicos se considera una actividad de diseño.
Un modelo de datos lógico sirve como base para un modelo de datos físicos,
incorporando requisitos comerciales y recopilando metadatos. El modelado de datos
lógico se puede realizar utilizando técnicas estándar y notaciones de modelado de
datos.
El modelado de datos es una actividad orientada a organizar la semántica de datos,

describir datos y abordar los límites de consistencia de los datos. Se puede
comparar con el dibujo de un arquitecto o el esquema de construcción, que forma la
base para el modelado conceptual y establece las relaciones entre varios
componentes de datos.
Las técnicas de modelado de datos se clasifican en una de dos categorías:

 Modelo entidad-relación (E-R)
 UML (Lenguaje unificado de modelado)
El modelado de datos lógico pertenece al modelo de relación de entidad, construido

con un diagrama de entidad-relación (conocido como ERD), una técnica de
modelado estándar utilizada como herramienta de comunicación por los
modeladores de datos en todo el mundo. Dentro de él, se encuentra el conjunto
completo de requisitos comerciales, pero no los componentes técnicos.
Diccionario de datos
Un diccionario de datos es un conjunto de definiciones que contiene las

características lógicas y puntuales de los datos que se van a utilizar en el sistema
que se programa, incluyendo nombre, descripción, alias, contenido y organización.
Identifica los procesos donde se emplean los datos y los sitios donde se necesita el
acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos
y auxilia a los analistas que participan en la determinación de los requerimientos del
sistema, su contenido también se emplea durante el diseño.
37
En un diccionario de datos se encuentra la lista de todos los elementos que forman

parte del flujo de datos de todo el sistema. Los elementos más importantes son flujos
de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles
y descripción de todos estos elementos.
Si los analistas desean conocer cuántos caracteres abarca un determinado dato o

qué otros nombres recibe en distintas partes del sistema, o dónde se utiliza,
encontrarán las respuestas en un diccionario de datos desarrollado en forma
apropiada.
El diccionario se desarrolla durante el análisis de flujo de datos y auxilia a los

analistas que participan en la determinación de los requerimientos de sistemas.
Razones para su utilización:
Para manejar los detalles en sistemas muy grandes, ya que tienen enormes
cantidades de datos, aun en los sistemas mas chicos hay gran cantidad de datos:
1. Los sistemas al sufrir cambios continuos, es muy difícil manejar todos los
detalles. Por eso se registra la información, ya sea sobre hoja de papel o
usando procesadores de texto. Los analistas mas organizados usan el
diccionario de datos automatizados diseñados específicamente para el
análisis y diseño de software.
2. Para asignarle un solo significado a cada uno de los elementos y actividades

del sistema: Los diccionarios de datos proporcionan asistencia para asegurar
significados comunes para los elementos y actividades del sistema y
registrando detalles adicionales relacionadas con el flujo de datos en el
sistema, de tal manera que todo pueda localizarse con rapidez.
3. Para documentar las características del sistema, incluyendo partes o

componentes así como los aspectos que los distinguen. Tambien es
necesario saber bajo que circunstancias se lleva a cabo cada proceso y con
que frecuencia ocurren. Produciendo una comprensión mas completa. Una
vez que las características están articuladas y registradas, todos los
participantes en el proyecto tendrán una fuente común de información con
respecto al sistema.
4. Para facilitar el análisis de los detalles con la finalidad de evaluar las

características y determinar donde efectuar cambios en el sistema.
5. Determina si son necesarias nuevas características o si están en orden los

cambios de cualquier tipo.
38
Se abordan las características:
 Naturaleza de las transacciones: las actividades de la empresa que se llevan

a cabo mientras se emplea el sistema.
 Preguntas: solicitudes para la recuperación o procesamiento de información

para generar una respuesta especifica.
 Archivos y bases de datos: detalles de las transacciones y registros maestros

que son de interés para la organización.
 Capacidad del sistema: Habilidad del sistema para aceptar, procesar y

almacenar transacciones y datos
Localizar errores y omisiones en el sistema, detectan dificultades, y las presentan en

un informe. Aun en los manuales, se revelan errores.
Contenido de un registro de diccionario:
El diccionario tiene dos tipos de descripciones para el flujo de datos del sistema, son
los elementos datos y estructura de datos.
 Elemento dato: son los bloques básicos para todos los demás datos del
sistema, por si mismos no le dan un significado suficiente al usuario. Se
agrupan para formar una estructura de datos.
 Descripción: Cada entrada en el diccionario consiste de un conjunto de

detalles que describen los datos utilizados o producidos por el sistema.
Cada uno está identificado con:
 Un nombre: para distinguir un dato de otro.
 Descripción: indica lo que representa en el sistema.
 Alias: porque un dato puede recibir varios nombres, dependiendo de quien

uso este dato.
 Longitud: porque es de importancia de saber la cantidad de espacio necesario

para cada dato.
39
 Valores de los datos: porque en algunos procesos solo son permitidos valores
muy específicos para los datos. Si los valores de los datos están restringidos
a un intervalo especifico, esto debe estar en la entrada del diccionario.
 Estructura de datos: es un grupo de datos que están relacionados con otros y

que en conjunto describen un componente del sistema.
Descripción:
Se construyen sobre cuatro relaciones de componentes. Se pueden utilizar las

siguientes combinaciones ya sea individualmente o en conjunción con alguna otra.
 Relación secuencial: define los componentes que siempre se incluyen en una

estructura de datos.
 Relación de selección: (uno u otro), define las alternativas para datos o

estructuras de datos incluidos en una estructura de datos.
 Relación de iteración: (repetitiva), define la repetición de un componente.
 Relación opcional: los datos pueden o no estar incluidos, o sea, una o

ninguna iteración.
Mapa de Navegación
Un mapa de navegación representa todas las pantallas distintas del sistema y cómo
se puede navegar entre ellas, esto es, con qué otras pantallas está conectada cada
pantalla.
40
Figura 9: Ejemplo de mapa de navegación sin representación de pantallas.
Cada pantalla se representa con una caja. En la caja está el nombre y,

opcionalmente, una representación gráfica de la pantalla. Las transiciones entre
pantallas se representan por medio de flechas.
No es necesario ser exhaustivo en la representación de las transiciones, puede

optarse por representar únicamente las más relevantes en el caso de que haya
muchas transiciones.
Diseño de Pantallas
En esta etapa se crea el diseño visual de cada una de las pantallas del prototipo. Se
definen los elementos gráficos, como botones, campos de entrada, tablas, etc., y se
establece la disposición y el estilo de los elementos en cada pantalla.
Desarrollo final del prototipo
Se implementa el prototipo utilizando herramientas de desarrollo de software. Se

crean las pantallas, se conectan entre sí y se agregan las funcionalidades
necesarias para simular el comportamiento final del sistema.
41
Casos de prueba del prototipo
En esta etapa se diseñan y ejecutan pruebas para verificar que el prototipo cumple
con los requisitos establecidos. Se crean casos de prueba que cubren diferentes
escenarios y se comprueba que el prototipo funciona correctamente y cumple con
las expectativas del usuario.
Es importante destacar que el diseño del prototipo es un proceso iterativo, lo que

significa que se pueden realizar ajustes y mejoras en cada etapa a medida que se
obtiene retroalimentación del usuario o se identifican nuevas necesidades.
Un caso de prueba es exactamente lo que parece: un escenario de prueba que mide

la funcionalidad en un conjunto de acciones o condiciones para verificar el resultado
esperado. Se aplican a cualquier aplicación de software, pueden utilizar pruebas
manuales o un prueba automatizaday puede hacer uso de herramientas de gestión
de casos de prueba.
Una cosa clave para recordar cuando se trata de escribir casos de prueba es que
están destinados a probar una variable o tarea básica, como si un código de
descuento se aplica o no al producto correcto en una página web de comercio
electrónico. Esto permite que un probador de software tenga más flexibilidad en
cómo probar el código y las funciones.
Script de prueba frente a caso de prueba
También debe aclararse la diferencia entre los casos de prueba y los scripts de
prueba. Un script de prueba es un programa corto destinado a probar ciertas
funciones. Un caso de prueba es un documento con pasos que deben completarse
según lo planeado con anticipación.
Considere los casos de prueba como un viaje meticulosamente planeado y los

guiones de prueba para que sean más como un viaje rápido a la tienda de
comestibles.
Diferentes tipos de casos de prueba
Los casos de prueba pueden medir muchos aspectos diferentes del código. Los
pasos involucrados también pueden tener la intención de inducir un resultado de
falla en lugar de un resultado esperado positivo, como cuando un usuario ingresa la
contraseña incorrecta en una pantalla de inicio de sesión.
42
Figura 10: Ejemplos de casos de prueba comunes.
Los casos de prueba se pueden aplicar a cualquier cantidad de funciones que se

encuentran en cualquier software dado. Algunos de los más populares incluyen:
 Ejemplo de prueba de API – Véalo en acción.

 Ejemplo de prueba de interfaz de usuario – Véalo en acción.
 Ejemplo de prueba unitaria – Véalo en acción.
 Ejemplo de prueba de carga y rendimiento – Véalo en acción.
 Prueba de seguridad
 Consultas SQL
 Prueba de aplicaciones de bajo código
Un ejemplo de caso de prueba popular
Los casos de prueba son útiles en una variedad de escenarios de software. Todo,
desde la banca hasta el software personal, requiere una aplicación de caso de
prueba. Por ejemplo, si el objetivo es tener datos confidenciales cifrados, el software
debe tener características que funcionen según lo previsto.
Pero las pruebas funcionales son solo un aspecto de la redacción de un caso de

prueba. Las pruebas de software deben desafiar enérgicamente todos los aspectos
del código, desde el rendimiento hasta la compatibilidad y la seguridad. Es por eso
que el software de cifrado personal debe probarse tan a fondo, especialmente
cuando se trata de cosas como API web.
43
Cómo escribir casos de prueba de software
La escritura de casos de prueba varía según lo que el caso de prueba esté midiendo
o probando. Esta es también una situación en la que compartir activos de prueba
entre los equipos de desarrollo y prueba puede acelerar las pruebas de software.
Pero todo comienza con saber cómo escribir un caso de prueba de manera efectiva
y eficiente. Los casos de prueba tienen algunas partes integrales que siempre deben
estar presentes en los campos. Sin embargo, cada caso de prueba se puede dividir
en 8 pasos básicos.
Paso 1: ID de caso de prueba
Todos los casos de prueba deben llevar ID únicos para representarlos. En la

mayoría de los casos, seguir una convención para este ID de nomenclatura
ayuda con la organización, la claridad y la comprensión.
Paso 2: Descripción de la prueba
Esta descripción debe detallar qué unidad, característica o función se está

probando o qué se está verificando.
Paso 3: Supuestos y condiciones previas
Esto implica que se cumplan las condiciones antes de la ejecución del caso de
prueba. Un ejemplo sería requerir una cuenta de Outlook válida para iniciar
sesión.
Paso 4: Datos de prueba
Esto se relaciona con las variables y sus valores en el caso de prueba. En el

ejemplo de un inicio de sesión por correo electrónico, sería el nombre de usuario
y la contraseña de la cuenta.
Paso 5: Pasos a ejecutar
Estos deben ser pasos fácilmente repetibles ejecutados desde la perspectiva del
usuario final. Por ejemplo, un caso de prueba para iniciar sesión en un servidor
de correo electrónico podría incluir estos pasos:
Abra la página web del servidor de correo electrónico.

Introduzca su nombre de usuario.
Introducir la contraseña.
Haga clic en el botón "Entrar" o "Iniciar sesión".
44
Paso 6: Resultado Esperado
Esto indica el resultado esperado después de la ejecución del paso del caso de
prueba. Al ingresar la información de inicio de sesión correcta, el resultado
esperado sería un inicio de sesión exitoso.
Paso 7: Resultado real y condiciones posteriores
En comparación con el resultado esperado, podemos determinar el estado del

caso de prueba. En el caso del inicio de sesión por correo electrónico, el usuario
iniciará sesión correctamente o no. La condición posterior es lo que sucede
como resultado de la ejecución del paso, como ser redirigido a la bandeja de
entrada del correo electrónico.
Paso 8: Contraseña errónea
La determinación del estado de aprobado / reprobado depende de cómo se

comparan entre sí el resultado esperado y el resultado real.
Mismo resultado = Aprobado

Diferentes resultados = Falla
Ejemplo de caso de prueba de calidad
Aunque los casos de prueba variarán según el tipo de prueba y el campo general de
prueba, la construcción de un caso de prueba de calidad se reduce a los pocos
elementos confiables anteriores. Recuerde: el nombre del método de prueba debe
incluir el método o la unidad bajo prueba y cuál es el resultado esperado.
También debe tenerse en cuenta que cada unidad debe probarse de forma aislada.
En este caso, "aislamiento" significa mantener las pruebas enfocadas tanto como
sea posible para ejecutar solo la parte de la aplicación que estamos probando.
Este ejemplo proviene de un caso de prueba relacionado con la banca:
Figura 11: Caso de prueba.
45
Con este nombre de método, sabemos que esta es una prueba unitaria que es:
 Probando el método 'isOverDrawn ()'.

 El balance utilizado para los datos controlados fue 500.
 El resultado esperado es cierto.
Un nombre de método significativo permite que cualquiera que revise los resultados
comprenda qué estaba probando la prueba unitaria. Además, indica los datos que se
van a probar, el resultado esperado y lo que se probó.
Si la prueba falla, conocer el resultado esperado es fundamental para facilitar la

resolución de problemas y asegurando que no se introduzcan regresiones.
46
REFERENCIAS BIBLIOGRÁFÍCAS
1. HubSpot. (2023). ¿Qué es la segmentación demográfica? Variables y ejemplos.

Obtenido de https://blog.hubspot.es/marketing/segmentacion-demografica
2. Sydle. (20 de mayo de 2023). Análisis de procesos: ¿qué es y cómo hacerlo?.

Obtenido de https://www.sydle.com/es/blog/analisis-de-procesos-
6197b230076d971ce272beff
3. PabsMOnestel. Análisis de problemas. Obtenido de

https://tutorialesdeaplicaciones.com/analisis-de-problemas/
4. Owius. (2023). El Alcance de un proyecto de desarrollo de software. Obtenido de

https://owius.com/el-alcance-de-un-proyecto-de-desarrollo-de-software/
5. Wikipedia. (7 de marzo de 2023). Requisito funcional. Obtenido de

https://es.wikipedia.org/wiki/Requisito_funcional#:~:text=Un%20requisito%20funcional
%20define%20una,de%20entradas%2C%20comportamientos%20y%20salidas.
6. Northware. (26 de mayo de 2022). Requerimientos en el desarrollo de software y

aplicaciones. Obtenido de https://www.northware.mx/blog/requerimientos-en-el-
desarrollo-de-software-y-aplicaciones/
7. IBM. ¿Qué son las reglas de negocio?. Obtenido de https://www.ibm.com/es-

es/topics/business-rules
8. Iebschool. (2023). Tipos de licencias de software: Todo lo que tienes que saber.
Obtenido de https://www.iebschool.com/blog/modelos-negocios-software-libre-open-
source-digital-business/
9. Keepcoding. (18 de agosto de 2022). Componentes del domain en un software.

Obtenido de https://keepcoding.io/blog/componentes-del-domain-en-un-software/
10. Erwin. (2023). ¿Qué es un modelo de datos?. Obtenido de https://www.erwin.com/mx-

es/solutions/data-modeling/data-model.aspx
11. Tibco. ¿Qué es un modelo de datos lógico?. Obtenido de

https://www.tibco.com/es/reference-center/what-is-a-logical-data-model
12. Ingeniería de Software. Diccionario de datos. Obtenido de

https://ingenieriadesoftwaretdea.weebly.com/diccionario-de-datos.html
13. Catedra Ocampo. (2023). Prototipos de bajo nivel y mapas de navegación. Obtenido
de https://catedraocampo.com.ar/prototipos-de-bajo-nivel-y-mapas-de-navegacion/
14. Parasoft. (27 de mayo de 2021). Cómo escribir casos de prueba para software:
ejemplos y tutorial. Obtenido de https://es.parasoft.com/blog/how-to-write-test-cases-
for-software-examples-tutorial/
47
REFERENCIAS DE IMÁGENES
Figura 1: Beneficios del BPMS

https://www.sydle.com/blog/assets/post/analisis-de-procesos-
6197b230076d971ce272beff/BPMS.png?w=720
Figura 2: Pasos para solucionar un problema.

https://tutorialesdeaplicaciones.com/wp-
content/uploads/2020/05/pasos_solucio%CC%81n_problemas-1-768x638.png
Figura 3: Identificar los datos intermedios

https://tutorialesdeaplicaciones.com/analisis-de-problemas/
Figura 4: Elementos por considerar en la definición del ámbito del producto.

https://www.mat.uson.mx/~mireles/conceptosProyectos/ambito.jpg
Figura 5: Recursos lógicos para controlar la disponibilidad de licencias

https://www.ibm.com/docs/es/workload-automation/9.3.0?topic=scenarios-specifying-
software-license-requirements-by-using-resources
Figura 6: Archivo de configuración.

https://www.ibm.com/docs/es/workload-automation/9.3.0?topic=scenarios-specifying-
software-license-requirements-by-using-resources
Figura 7. Componentes del domain en un software.

https://keepcoding.io/wp-content/uploads/2022/08/Componentes-del-domain-.jpg
Figura 8: Modelo de datos lógico.

https://www.tibco.com/sites/tibco/files/media_entity/2021-06/logical-data-model-
diagram.svg
Figura 9: Ejemplo de mapa de navegación sin representación de pantallas.

https://catedraocampo.com.ar/wp-
content/uploads/2019/09/EjemploMapaNavegacion.jpg
Figura 10: Ejemplos de casos de prueba comunes.

https://www.parasoft.com/wp-content/uploads/2021/05/table-test-case-
examples.png.webp
48
Figura 11: Caso de prueba.

https://www.parasoft.com/wp-content/uploads/2021/05/code-2.png.webp
49

Piad-516 Material

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Piad-516 Material

Cargado por

Copyright:

Formatos disponibles

Software y Prototipado

Demografía del mercado

 Ventajas de la segmentación demográfica

Los datos son fáciles de obtener

Datos fáciles de analizar

Ayuda a desarrollar presencia en el mercado

Mejora tus productos y servicios

Optimiza tus estrategias de marketing

Inclusive, realizar una segmentación demográfica correcta también te permite

 Desventajas de la segmentación demográfica

La información es muy básica

Aunque brinda información importante que debes conocer, lo cierto es que

No ofrecen ventaja competitiva

Como ya lo mencionamos, este tipo de segmentación de mercado no te

La información obtenida no es perdurable

El análisis de procesos te permite revisar y tener un amplio conocimiento de los

 El objetivo: si está de acuerdo con las metas establecidas en la planificación

¿Cuál es el objetivo del análisis de procesos?

Al tener una visión completa es posible identificar los fallos y las

¿Y cuáles son los beneficios de esto?

¿Cuándo hacer un análisis de procesos?

Al fin y al cabo, las interferencias externas e internas se producen

Según la guía BPM CBOK, se debe priorizar el análisis de procesos cuando:

¿Cómo hacer un análisis de procesos?

 El mapeo y el análisis de los procesos deben hacerse no sólo con

 Con este diagnóstico, los gestores podrán justificar futuras modificaciones

 Entender el escenario: a continuación, es importante entender el entorno

 Establecer el alcance de los procesos que se incluirán en el análisis. Define

 Definir el método: es necesario elegir el enfoque del análisis y la forma en

 Definir el proceso AS IS: estudia el proceso tal y como funciona

 Especificar los puntos de mejora: después de definir el proceso tal y como

 Modelar el proceso TO BE: crear el modelo del proceso teniendo en cuenta

Al realizar el análisis, recuerda documentar todo el proceso y evaluar las cuestiones

 Costos y asignación de recursos

Figura 1: Beneficios del BPMS

La herramienta es capaz de centralizar en un mismo sistema toda la información

Análisis del Problema

El análisis de problemas es una de las cualidades básicas que todo desarrollador

Sin embargo ese diseño de las soluciones surge de la capacidad que un

Proceso para solucionar un problema

 Para solucionar un problema se sigue la metodología del pensamiento

Figura 2: Pasos para solucionar un problema.

Definición del problema

 Los problemas que se pueden solucionar mediante un programa de

 Aquellos problemas cuya solución sea abstracta, poco clara, confusa o

 Por ejemplo: «eliminar la contaminación de los océanos», es un problema

 Sin embargo, determinar el nivel de contaminación del agua en un país, si es

Conceptos básicos para el análisis

 Datos de entrada: aquellos datos que hay que solicitarle al usuario

 Datos intermedios: aquellos datos que el problema no indica pero que

Antes de empezar a solucionar un problema, se debe analizar e identificar qué

El proceso de análisis debe realizarse siempre antes de empezar a escribir código, o

Se recomienda seguir los siguientes pasos al analizar un problema.

1. Analizar, estudiar y comprender el problema para decidir si ocupamos

Pablo tiene hambre por eso va al restaurante a comprar papitas y refrescos.

Según el problema anterior se ocupan saber cuántas papitas y cuántos refrescos

 Cantidad de papitas que Pablo desea comprar

Por otro lado no hay constantes que se puedan apreciar en el mismo.

 Datos establecidos o constantes

Identificar los datos intermedios

Por ejemplo al pensar en una factura de un restaurante, recordamos que

Figura 3: Identificar los datos intermedios.

El diseño es la solución del problema, generalmente son la secuencia de pasos