Modelado de negocio

1. Modelo de negocio
Joan Sebastián Ramírez Pérez
2015

2. Agenda
 Requisitos
 Modelo de negocio
 Bibliografía

3. Agenda
 Requisitos
 Modelo de negocio
 Bibliografía

4. ¿Qué es un requisito?
 Una especificación de qué se debería implementar. Son descripciones de cómo se
debe comportar el sistema, o de un atributo o propiedad del sistema. Puede ser
una restricción en el proceso de desarrollo de un sistema (Somerville y
Sawler,(1997)).
 Cada objetivo del sistema debe contestarse con uno o varios requisitos. El requisito
debe establecerse de forma que la métrica pueda responderlo claramente.

5. ¿Qué no es un requisito?
 Detalles de Diseño o implementación o pruebas.
 Información relativa a la Planificación del Proyecto.
 Necesidades del Proyecto.

6. Los requisitos deben ser:
 Posibles
 Necesarios
 Priorizados
 Concretos
 Verificables

7. Importancia de los requisitos
Defecto Consecuencia
Implicación insuficiente del cliente Problemas en la validación del producto obtenido
Requisitos crecientes y cambiantes
Degradación de la estructura y arquitectura del
producto
Requisitos ambiguos Pérdida de tiempo en re-codificación
Requisitos innecesarios Trabajo innecesario
Requisitos insuficientes (mínimos)
Problemas en la validación del producto obtenido y
error en la estimación
y planificación
Omisión de las necesidades de algunos grupos de usuarios Usuarios insatisfechos

8. Ingeniería de requisitos

9. Ingeniería de requisitos

10. Desarrollo de requisitos

11. Buenas practicas

12. Técnicas de elicitación de requisitos
 Entrevistas.
 Joint Application Development (JAD) o Desarrollo Conjunto de Aplicaciones.
 Brainstorming o tormenta de ideas.
 Utilización de escenarios o casos de uso.

13. Entrevistas
 Es la técnica más usada
 Cuenta con tres fases: preparación, realización y análisis.
 Preparación: estudio dominio de problema, seleccionar personas a entrevistar,
determinar el objetivo de cada entrevista y planificación de la entrevista (fecha,
hora, lugar y duración).
 Realización: apertura (se informan objetivos y se expresan conceptos necesarios
para la entrevista), desarrollo (preguntas abiertas) y terminación (se recapitula para
estar seguros de la información obtenida).
 Análisis: se revisan las notas o grabaciones obtenidas de la entrevista con el fin de
obtener un documento con la información. Dicho documento se podría validar con
el entrevistado.

14. Joint Application Development (JAD) o
Desarrollo Conjunto de Aplicaciones
 Desarrollada por IBM en 1977.
 Se desarrolla a lo largo de un conjunto de reuniones en grupo durante un periodo
de 2 a 4 días. En estas reuniones se ayuda a los clientes y usuarios a formular
problemas y explorar posibles soluciones, involucrándolos y haciéndolos sentirse
partícipes del desarrollo.
 Se basa en 4 principios : dinámica de grupo, el uso de ayudas visuales para mejorar
la comunicación (diagramas, transparencias, multimedia, herramientas CASE, etc.),
mantener un proceso organizado y racional y una filosofía de documentación
WYSIWYG (What You See Is What You Get).
 El JAD tiene dos pasos: el JAD/Plan (busca elicitar y especificar requisitos) y el
JAD/Design (aborda el diseño del software).

15. Brainstorming o tormenta de ideas
 Técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un
ambiente libre de críticas o juicios.
 Cada sesión esta formada por un número de cuatro a diez participantes. Uno de los
cuales es el jefe de la sesión, encargado más de comenzar la sesión que de
controlarla.
 Frente al JAD, el brainstorming tiene la ventaja de que es muy fácil de aprender y
requiere poca organización.
 Tiene 4 fases: preparación (lugar, fecha y participantes), generación (el jefe abre la
sesión exponiendo un enunciado general del problema a tratar, que hace de
semilla para que se vayan generando ideas.), consolidación (revisión ideas,
descartar ideas, priorizar ideas) y documentación (el jefe documenta el resultado
de la dinámica).

16. Utilización de escenarios o casos de uso
 Los casos de uso facilitan la elicitación de requisitos y son fácilmente
comprensibles por los clientes y usuarios.
 La utilización de los casos de uso como técnica tanto de elicitación como de
especificación de los requisitos funcionales del sistema.

17. Tipos de requisitos (Juan Palacios)
 Funcionales: definen el comportamiento del sistema o tareas que el sistema debe
realizar.
 No funcionales: definen aspectos, que sin ser funcionalidades, (tareas que el sistema
debe realizar) resultan deseables desde el punto de vista del usuario. Generalmente
comprenden atributos de calidad: tiempos de respuesta, características de usabilidad y
facilidad de mantenimiento.
 De interfaz: definen las interacciones del sistema con su entorno.

18. Tipos de requisitos (Amador Duran)
 Objetivos del sistema
 Requisitos de información
 Requisitos funcionales
- Diagramas de casos de uso
- Definición de actores
- Casos de uso del sistema
 Requisitos no funcionales

19. Tipos de requisitos

20. Atributos de calidad

21. Visibles Vía Ejecución
Atributo de calidad Descripción
Disponibilidad (Availability) Es la medida de disponibilidad del sistema para el uso.
Confidencialidad (Confidentiality) Es la ausencia de acceso no autorizado a la información.
Funcionalidad (Functionality)
Habilidad del sistema para realizar el trabajo para el cual fue
concebido.
Desempeño (Performance)
Es el grado en el cual un sistema o componente cumple con
sus funciones designadas, dentro de ciertas restricciones
dadas, como velocidad, exactitud o uso de memoria
Confiabilidad (Reliability)
Es la medida de la habilidad de un sistema a mantenerse
operativo a lo largo del tiempo.
Seguridad externa (Safety)
Ausencia de consecuencias catastróficas en el ambiente. Es
la medida de ausencia de errores que generan pérdidas de
información
Seguridad interna (Security)
Es la medida de la habilidad del sistema para resistir a
intentos de uso no autorizados y negación del servicio,
mientras se sirve a usuarios legítimos

22. No visibles vía ejecución
Atributo de calidad Descripción
Configurabilidad (Configurability)
Posibilidad que se otorga a un usuario experto a realizar ciertos
cambios al sistema.
Interoperabilidad (Interoperability)
Es la medida en que trabajan correctamente componentes del
sistema que fueron desarrollados separadamente al ser
integrados.
Integridad (Integrity) Es la ausencia de alteraciones inapropiadas de la información.
Modificabilidad (Modifiability) Es la habilidad de realizar cambios futuros al sistema.
Mantenibilidad (Maintainability)
Es la capacidad de someter a un sistema a reparaciones y evolución.
Capacidad de modificar el sistema de manera rápida y a bajo costo.
Portabilidad (Portability)
Es la habilidad del sistema para ser ejecutado en diferentes ambientes de computación. Estos
ambientes pueden ser hardware, software o una combinación de los dos.
Reusabilidad (Reusability)
Es la capacidad de diseñar un sistema de forma tal que su estructura o parte de sus componentes
puedan ser reutilizados en futuras aplicaciones.
Escalabilidad (Scalability) Es el grado con el que se pueden ampliar el diseño arquitectónico, de datos o procedimental
Capacidad de Prueba (Testability)
Es la medida de la facilidad con la que el software, al ser sometido a una serie de pruebas, puede
demostrar sus fallas.
Es la probabilidad de que, asumiendo que tiene al menos una falla, el software fallará en su
próxima ejecución de prueba

23. Agenda
 Requisitos
 Modelo de negocio
 Bibliografía

24. ¿Qué es un modelo de negocio?
 Un modelo del dominio es una representación visual de los conceptos
sobresalientes y significativos u objetos en el dominio de interés (contexto del
sistema).
 Es un diccionario visual de conceptos y sus relaciones. Se usan para entender los
conceptos claves y el vocabulario.
 Muestra conceptos, relaciones entre conceptos y atributos de los conceptos.
 Es la representación de cosas del mundo real, no componentes de software.

25. ¿Qué no es?
 No es un modelo de datos.
 No es un diagrama de clases de software. Aunque se usa la notación de un
diagrama de clases UML.
 No es una descripción del diseño del software

26. ¿Qué es y qué no es?

28. Ejemplo
 La figura muestra un modelo de dominio parcial, con la notación de un diagrama de
clases de UML. Muestra que las clases conceptuales cliente, video tienda, y video son
significativas para el dominio.
 Así mismo muestra que la video tienda y el video se relacionan de una forma que es
importante mostrarla (La tienda de videos almacena varios videos), y que la video tienda
tiene atributos como dirección, nombre y número telefónico, que nos interesan en el
dominio.

29. Guía al modelo de diseño

30. Clases conceptuales
 El modelo del dominio ilustra clases conceptuales o vocabulario en el dominio.
 Una clase conceptual es una idea, cosa u objeto.

31. Clases conceptuales
 Símbolo: palabras o imágenes que
representan la clase conceptual.
 Intensión: definición de la clase.
 Extensión: conjunto de ejemplos para
los cuales aplica la clase conceptual.

32. ¿Cómo se hace un modelo de dominio?
 Use los requisitos que tiene hasta el momento.
 Encuentre las clases conceptuales.
 Dibújelas como clases en un diagrama de clases UML.
 Agregue asociaciones y atributos.
 Actualícelo frecuentemente sin caer en desperdicios de esfuerzo.

33. ¿Cómo identifico las clases conceptuales?
1. Reusar o modificar modelos existentes.
2. Usar una lista de categorías
3. Análisis lingüístico: identificar sustantivos y frases sustantivas.
 Identificarlos en las descripciones textuales del dominio del problema y considerarlos
como clases candidatas o atributos.
 Utilizar los casos de uso para identificar sustantivos.

34. Categorías
Categorías de conceptos
 Transacciones de negocio (Criticas si involucran dinero)
 Ítems de transacciones, líneas de artículos.
 Producto o servicio relacionado a la transacción.
 Objetos físicos o tangibles (Relevante en software de control de
dispositivos o simulaciones)
 Especificaciones, diseños o descripción de cosas. Catálogos.
 Lugares de transacciones o donde se presta el servicio.
 Roles de personas u organizaciones, actores . (Partes involucradas
en la transacción)
 Contenedores de cosas o información. Cosas en el contenedor.
 Registros financieros, contratos, aspectos legales.
 Instrumentos financieros
 Manuales, horarios, documentos.
Ejemplos
 Venta, Pago. Reserva.
 Línea de productos.
 Ítem de venta.
 POS (point of sale)
 Descripción de productos, Catálogo de productos. Descripción de
vuelos
 Almacén, aeropuerto, avión
 Cajero, cliente. Pasajero, aerolínea.
 Almacén, estante, bodega. Avión. Artículo. Pasajero.
 Registro de mantenimiento, libro mayor.
 Cheque, tarjeta crédito, efectivo. Tiquetes.
 Lista de precios. Calendario de reparaciones.

35. Atributos vs clases
 Si no podemos identificar una clase conceptual como número o texto en el mundo
real, probablemente es una clase y no un atributo.
 Los atributos son datos simples.

36. Asociaciones
 Una asociación es una relación entre conceptos que indica alguna conexión
significativa e interesante.

37. ¿Qué no son las asociaciones?
 Un modelo de flujo de datos
 Claves foráneas de una bases de datos
 Instancias de variables
 Conexiones de objetos de software

38. ¿Cómo se nombran las asociaciones?
 La dirección de lectura por defecto para la
asociación es de izquierda a derecha y de
arriba a abajo.
 El nombre debe comenzar con mayúscula
porque la asociación representa un
clasificador de enlaces entre instancias.
(UML )
 Cada extremo de la asociación es llamado
ROL. (tiene multiplicidad)

39. Multiplicidad
 La multiplicidad define cuantas
instancias de una clase se pueden
relacionar con una instancia de otra
clase, en un momento del tiempo
particular.
 Puede existir más de una asociación
entre dos clases
 Por ejemplo, una instancia de Store
puede ser asociada con “varias”
(cero o mas) instancias de Item.

40. Atributos
 Es un valor de un dato lógico de un objeto que necesita ser recordado.
Algunos atributos son derivados de otros.
 Datos primitivos
–Números, caracteres, booleanos
 Tipos de datos compuestos comunes
–Date, time, dateTime, dirección, número de telefono, código de barras, etc.
 Las conexiones a otros conceptos se representan como asociaciones y no como
atributos.

41. Notación

42. ¿Cuándo descomponer en subclases?
 La subclase adiciona atributos de interés.
 La subclase adiciona asociaciones de interés.
 El concepto de la subclase es operado, o manipulado diferentemente que la
superclase u otras subclases.

43. Multiplicidad

44. Agenda
 Requisitos
 Modelo de negocio
 Bibliografía

45. Bibliografía
 Amador Durán Toro, Beatriz Bernárdez Jiménez, "Metodología para la Elicitación de
Requisitos de Sistemas Software", Versión 2.3, Informe Técnico LSI–2000–10
(revisado), Universidad de Sevilla.
 Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The UML Modeling LanguageUser
Guide. Adisson-Wesley.
 Pressman R. (2002) Ingeniería de Software. Un Enfoque Práctico. Quinta Edición. Mc
Graw Hill.
 Larman, C. “UML y Patrones. Introducción al Análisis y Diseño Orientado a Objetos
y al Proceso Unificado”. Prentice Hall, 2004.
 Grupo de Investigación Kybele. Ingeniería de Requisitos y Calidad de Producto.
Universidad Rey Juan Carlos

47. Gracias