Módulo 2.

Disciplina de modelado de negocio y

requerimientos

En este segundo módulo completaremos la visión general del proceso que es

conducido por los casos de uso. Esta mirada nos permitirá finalizar el conocimiento
de los modelos restantes para el proceso de desarrollo de software unificado.

Así, teniendo esta perspectiva general de la estructura o esqueleto del proceso, en

términos de conceptos, lenguaje de modelado (en inglés, UML), diagramas, fases,
etcétera, nos interiorizaremos en las disciplinas del proceso (requerimientos,
análisis, diseño, implementación y test).

Comprendiendo las diferentes disciplinas del proceso, su interacción con las

diferentes fases, los roles que intervienen, los artefactos por generar y los flujos de
trabajo, tendremos una visión detallada del sistema final.

Video de inmersión

Unidad 2.1. Visión general del proceso conducido por casos de uso II

Unidad 2.2. Captura de requisitos

Video de habilidades

Cierre

Glosario de términos

Referencias

Descargá la lectura
Lección 1 de 8

Video de inmersión

temporarily blocked
Pardon the inconvenience, but our servers have
detected a high number of errors from your
connection. To continue, please verify that you
are a human:

I'm not a robot

reCAPTCHA
Privacy - Terms
Lección 2 de 8

Unidad 2.1. Visión general del proceso conducido por

casos de uso II

Continuando con la unidad anterior, presentaremos modelos en términos generales para continuar con
nuestra visión del proceso.

2.1.1 Modelo de diseño

Tomando como punto de partida el modelo de análisis y el de requerimientos, construimos el modelo de

diseño; este es el encargado de modelar el sistema de información para que soporte requisitos
funcionales y no funcionales.

La disciplina de diseño es la que comienza en la fase de construcción, donde podemos ir realizando las
iteraciones de las funcionalidades que queremos ir incrementado (recordá que es un proceso iterativo e
incremental), de acuerdo con la priorización efectuada anteriormente con los usuarios del sistema.

Este modelo, a diferencia del análisis, es un modelo ya no conceptual, sino más bien físico, que
especifica detalles para su posterior implementación, por lo que también su carácter está más centrado
en la secuencia, ya que posteriormente se tiene que desarrollar e implementar.

2.1.2 Modelo de implementación

Figura 1. Diagrama de clase

 Fuente: elaboración propia con base en Oviedo, J. (2011)

Seguimos en la fase de construcción y, tomando el resultado del diseño, realizamos la implementación

en términos de componentes del software, como scripts, código fuente, ejecutables, ficheros de
despliegue y afines.

Se planifican las integraciones producidas en cada iteración.

Figura 2. Vista arquitectónica del despliegue

 Fuente: elaboración propia con base en el documento Habilitación profesional Oviedo, J.
(2011).

2.1.3 Prueba de casos de uso

El objetivo es planificar las pruebas en cada iteración producida, ya que en cada incremento se agrega
funcionalidad y esta debe ser testeada. Para esto, se diseñan casos de prueba y se los documenta para
posteriormente ejecutarlos y guardar una trazabilidad de estos.

En esta etapa se realizan test en diferentes capas del sistema. Si vamos de lo más específico a lo más
general, podemos mencionar diferentes tipos de test, como test unitarios, test de rendimiento con
cualesquiera de sus variantes (carga, estrés, pico, estabilidad, etc.) e interfaz de usuario.

¿En qué fase del proceso de desarrollo unificado comienza el modelo de diseño?

Fase inicial.

Fase de elaboración.

Fase de construcción.

Fase de transición.

SUBMIT
Lección 3 de 8

Unidad 2.2. Captura de requisitos

Hemos completado una visión general del proceso de desarrollo unificado; es hora de que ahondemos en
las disciplinas del proceso. Para esto, pensamos ejemplificar y mantener el mismo ejemplo a lo largo de
todas las disciplinas, así podremos ir entendiendo cómo cada una de ellas nos proporciona información
relevante sobre diferentes aristas.

Imaginaremos que una empresa ha decidido contratar nuestros servicios para realizar un sistema de
software y que, si bien tiene la idea de automatizar toda la organización, ha decidido comenzar por el
proceso de selección de personal.

Hasta ahora no tenemos mucha información, por lo que tendremos que pedir que nos envíen un manual
de procedimiento. Pero nos informan que la empresa no lo posee, así que optamos por solicitar un
modelo de negocio o modelo de dominio, aunque tampoco cuentan con ello.

¿Porque solicitamos esta documentación? Simplemente porque es una forma de conocer si tienen un
procedimiento formal y también es una manera de entender el proceso que realizan para la selección de
personal. Recordá que una de las formas de capturar requisitos es a partir del modelo de negocio o
modelo de dominio.

Volvamos al ejemplo: como no contamos con la información solicitada, necesitamos otra forma de
relevarla. Para esto, recurrimos a entrevistas, encuestas, cuestionarios, etcétera.

Concluido el relevamiento, hemos podido entender que el objetivo es desarrollar un sistema de

información que gestione, a partir de una necesidad de cubrir un puesto, el reclutamiento y la selección
de personal, tanto externo como interno. Este debe incluir la gestión de carga del curriculum vitae (CV),
la búsqueda automática de postulantes de acuerdo con características definidas en el perfil, la citación
del postulante y el seguimiento de las etapas en el proceso de selección, como así también los envíos
automáticos de e-mails informando actualizaciones del curriculum vitae, búsquedas activas, estado del
postulante en el proceso de selección y búsquedas coincidentes con el perfil. Esto es,
significativamente, una idea más detallada que solo un proceso de selección de personal.

2.2.1 Modelo de negocio - modelo de dominio

Modelo de negocio

Comenzaremos por el modelo de negocio, ya que algunas empresas cuentan con este modelo. De todos
modos, si no contaran con esta información, tendríamos que desarrollarla con la información que
hayamos obtenido de los métodos de relevamiento de información seleccionados.

Siguiendo con nuestro ejemplo de selección de postulantes, hemos creado el siguiente diagrama.

Figura 3. Modelo de negocio

 Fuente: elaboración propia con base en Oviedo, J. (2011)

Hemos confeccionado el modelo de negocio a través de UML (lenguaje unificado de modelado). Este
puede ser representado por dos modelos propuestos por el lenguaje de modelado: el modelo de objetos y
el modelo de casos de uso. En este caso, hemos seleccionado este último, que es el que se muestra en
la figura 3.

El diagrama de la figura 3 nos muestra gráficamente el contexto del sistema desde la perspectiva del
usuario. A medida que vayamos utilizando UML, iremos describiendo su notación, tal como lo hacemos a
continuación de la siguiente figura.

Figura 4. Notación UML

 Fuente: elaboración propia.

Actor de negocio: representa un rol en relación con el negocio, por algo o alguien en el
entorno del negocio, por ejemplo: clientes, proveedores, autoridades locales,
organizaciones, socios, etcétera.

Caso de uso: representa una funcionalidad manejada, requerida o usada por los
trabajadores del negocio, un documento o una parte esencial de un producto, y a veces algo
menos tangible como el conocimiento sobre el mercado o sobre un cliente. Es representado
por óvalos y el texto dentro de estos representa la función del sistema.

¿Podríamos detallar más? Sí. Si bien no es parte del modelo de dominio, lo mencionamos aquí porque la
descripción de los casos de uso del negocio se basa en el modelo de negocio. A modo de ejemplo,
hemos decidido describir uno, solamente la funcionalidad que se refiere a receptar currículum.

 Nota: en la plantilla de descripción se ha tildado nivel de use case de negocio, no de

sistema de información.

Tabla 1. Caso de uso

Fuente: elaboración propia con base en Oviedo, J. (2011)
Modelo de dominio

El modelo de dominio se describe utilizando el diagrama de clases de UML. Este último especifica
clases obtenidas de la especificación de los requisitos. El objeto del modelo del dominio es comprender
y describir las clases más importantes dentro del contexto del sistema.

El diagrama de clases determina las distintas clases con sus interrelaciones, por ejemplo, herencia,
asociación y agregación. Además, las clases poseen atributos que son propiedades de estas.

A continuación, se presenta la primera versión del modelo que se realiza siguiendo el ejemplo
seleccionado, que luego deberá ser refinada con el resto de las clases, métodos y atributos, durante el
diseño.

Figura 5. Modelo de dominio

Fuente: elaboración propia.

Veamos un poco de notación: las clases se representan con rectángulos. Estos están divididos en tres
partes, la parte superior indica el nombre de la clase; la parte intermedia o central, los atributos; y la
inferior, las acciones u operaciones. Las asociaciones representan las relaciones entre las clases.

Como es un primer bosquejo que luego iremos refinando, vamos a dejar pendiente para nuestro diagrama
la multiplicidad, la composición, la agregación y la generalización.

¿Qué podemos inferir con base en este diagrama? Que un currículum se refiere a varias etapas
(entrevista técnica, entrevista personal, propuesta económica, etc.), esa búsqueda y cada una de esas
etapas tienen un estado (pendiente, apto o no apto) y necesitamos que los campos mencionados
interactúen en el diagrama. Básicamente, seguimos comprendiendo el contexto del sistema.

 Nota: el diagrama de dominio también puede ser completado al momento de realizar

prototipos de interfaces, tema que veremos en esta misma unidad.

2.2.2 Requerimientos funcionales y no funcionales

Nos ayudaría mucho listar los requerimientos funcionales (qué hace el sistema) y no funcionales (cómo
lo hace). En nuestro sistema de ejemplo serían los que se detallan a continuación.

F UN C I O N A L E S N O F UN C I O N A L E S

Registro de la información de las personas interesadas en trabajaren la empresa: datos personales,

experiencia laboral, datos educacionales, cursos o seminarios y los sectores de interés.

Información sistematizada sobre el seguimiento del candidato en el proceso selección.

Publicación interna sobre las diferentes vacantes en la empresa.

Envíos de e-mails masivos a postulantes para actualización de datos y búsquedas activas.

Informes estadísticos sobre CV cargados y postulantes coincidentes con los perfiles buscados.

Registro de los datos de las búsquedas que se realizan de forma externa e interna.
Diagramación de las citaciones a los postulantes a través de una herramienta estilo calendario.

Control de usuarios con los diferentes perfiles y accesos al sistema.

Emisión de listados de candidatos por fecha de citas.

Registro de los conocimientos que poseen los candidatos.

F UN C I O N A L E S N O F UN C I O N A L E S

El sistema debe estar permanentemente disponible para ofrecer servicios a los usuarios, los 7 días
de la semana, las 24 horas del día.

En caso de fallas de algún componente, no debe haber pérdida de información.

Si el aplicativo falla, debe existir mecanismos que salvaguarden la interrupción de transacciones y

garanticen su finalización de manera correcta, respondiendo de manera adecuada a los
requerimientos de consistencia transaccional.

Considerando la alta sensibilidad de la información que maneja según las especificaciones

funcionales dadas, la solución debe manifestar patrones de seguridad.

El sistema debe ser construido e implantado de tal manera que un cambio en los parámetros de
negocio no obligue a la generación de una nueva versión del módulo.

Si se tiene una alta demanda acorde con los requerimientos funcionales y no funcionales de la
solución, el sistema debe ofrecer un buen desempeño, en un tiempo no mayor a 3 segundos sobre
operaciones transaccionales.

Sistema en plataforma web.

Lenguaje de programación Python.

Almacenamiento de datos en Microsoft SQL Server.

La solución que el sistema procure debe ofrecer las interfaces para intercambiar información e
integrarse con otros sistemas, como el sistema de nóminas de empleados.

La solución debe ofrecer niveles de servicio apropiados que garanticen la disponibilidad y la

recuperación de fallos.
Conocer los requerimientos (funcionales y no funcionales) nos ha ayudado a disminuir la incertidumbre.
Nuestro conocimiento es más claro, pero, si tuviésemos que planificar cada una de las características
(requerimientos), ¿cuál implementaríamos primero?, ¿cuánto tiempo nos tomaría implementarla? Es
evidente que no podemos contestar estas preguntas.

Falta priorizar nuestros conocimientos, interpretarlos, determinar su complejidad, su riesgo, etcétera, A

continuación, mostramos cómo han quedado los requerimientos aplicados a nuestro ejemplo.

Tabla 2. Requerimientos aplicados 

 Fuente: elaboración propia con base en Oviedo, J. (2011)

Diagrama de caso de uso

Es hora, entonces, de modelar con UML la funcionalidad del sistema de información a través del modelo
de caso de uso. Para esto, ejemplificaremos el diagrama de casos de uso con una cantidad acotada de
estos, para hacerlo más simple, y describiremos uno de ellos.

En el siguiente diagrama mostraremos los procesos que lleva a cabo el sistema de información, teniendo
en cuenta los procesos esenciales, como aquellos que sirven de soporte al sistema, y la relación de los
usuarios con cada uno de estos.

Figura 6. Diagrama de caso de uso 

 Fuente: elaboración propia.

Prototipo de interfaz de usuario

¿Podemos seguir captando requerimientos de otra forma? Sí, podemos realizar prototipos de interfaz de
usuario, que nos ayudarán a entender las interacciones entre los usuarios y el sistema. Para esto, nos
basaremos en los casos de uso.

Cuando hacemos referencia a interfaz de usuario para un sistema de información, estamos hablando de
las pantallas, los mensajes, los reportes, etcétera, de dicho sistema.

A continuación, vamos a prototipar las interfaces continuando con el ejemplo del proceso de selección.

Figura 7. Prototipo N.° 1

Fuente: elaboración propia con base en Oviedo, J. (2011)

Figura 8. Prototipo N.° 2

Fuente: elaboración propia con base en Oviedo, J. (2011)

Figura 9. Prototipo N.° 3

 Fuente: elaboración propia con base en Oviedo, J. (2011)

Además de prototipar las interfaces, para captar los requisitos vamos a generar un glosario del sistema
de información, que por motivos de comodidad lo hemos incluido al final del documento.

2.2.3 Roles y artefactos

Como verás, captar requisitos no es tarea sencilla. Llegado este momento, te preguntarás quién realiza
todo este trabajo. A continuación, listamos los roles que intervienen en el proceso y los artefactos o
productos que se deben generar.
Tabla 3. Artefactos por roles

Artefacto de entrada Rol Artefacto de salida

Modelo casos de uso

Modelo de negocio
(esbozo)

Analista de sistemas
Modelo de dominio
Glosario
Listado de requerimientos

Modelo casos de uso

(esbozo

Especificador de casos de Modelo de casos de uso

Glosario uso (detallado)

Listado de requerimientos

Modelo de casos de uso

(detallado)

Diseñador de interfaz de Prototipo de interfaz de

Glosario usuario usuario

Listado de requerimientos

Modelo casos de uso

(esbozo)
Descripción de
Arquitecto arquitectura (vista del
Glosario
modelo de casos de uso)

Listado de requerimientos
Fuente: elaboración propia con base en Jacobson, I., Booch, G., Rumbaug, J. (1999) recuperado

dehttps://goo.gl/ruj8nS

Cabe mencionar que, si bien tenemos varios roles, esto no implica que debamos tener una persona para
cada rol. Supongamos que el sistema de información por desarrollar es sencillo, simple y no tiene gran
envergadura; estos roles podrían ser ejecutados por una persona, por lo tanto, evidenciamos que el rol
hace referencia a la función o al comportamiento que tiene que desarrollar una o varias personas en un
momento dado.

2.2.4 Flujo de trabajo

La sucesión de actividades es lo que nos especifica el flujo de trabajo y los roles responsables de
terminar los artefactos por producir. A continuación, detallaremos esa secuencia de actividades.

Tomando como punto de partida el modelo de negocio, describimos en detalle los procesos y alcances
que existen en el sistema de información, utilizando las herramientas del Proceso Unificado de Desarrollo
de Software y el lenguaje UML.

En una primera parte, se presenta un diagrama de casos de uso del sistema para describir todos y cada
uno de los procesos que realiza el sistema de información.

Luego se realiza una descripción de cada caso de uso para ver los detalles y los distintos caminos
alternativos de cada uno, y se los prioriza para determinar el orden de importancia.

Como consecuencia de esta información, definimos los prototipos de interfaz correspondientes, que
darán como resultado el modelo de dominio con las clases que participarán en la solución planteada.

El relevamiento de requerimientos es una de las partes más

importantes del proceso uni cado de desarrollo. 
El objetivo del modelado de los requerimientos es describir las necesidades de la empresa que serán
resueltas con el sistema.

El modelo de requerimientos es una entrada fundamental para el flujo de trabajo del análisis y el diseño.
Los principales procesos de la empresa estarán enunciados en el diagrama de casos de uso y detallados
en cada descripción del caso de uso.

El prototipo de interfaz nos proporciona ayuda para ir completando, ¿qué cosa?

Modelo de negocio.

Diagrama de use case.

Modelo de dominio.

Glosario.

SUBMIT
Lección 4 de 8

Video de habilidades

Ingeniería del Software II - Modelado de clases con UML - …

Un diagrama de clase es un tipo de diagrama de estructura estática.

Verdadero.

Falso.
 SUBMIT

¿Qué figura geométrica se utiliza en el lenguaje UML para representar una

clase?

Circulo.

Ovalo.

Rectángulo.

Elipse.

Rombo.

SUBMIT

¿Cuál es otro nombre para la relación entre clases de tipo generalización, donde
una clase específica es una versión de la otra clase general?
 Polimorfismo.

Interfaz.

Encapsulamiento.

Herencia.

Componente.

SUBMIT

¿Cuál es otro nombre para la relación entre clases de tipo realización?

Polimorfismo.

Interfaz.

Encapsulamiento.

Herencia.

Componente.
 SUBMIT

La notación UML de las clases divide el objeto en tres partes (parte superior,
central e inferior), ¿qué información se define en la parte central?

Nombre de clase.

Métodos.

Nombre de paquete.

Tipo de relación.

Atributos.

SUBMIT
Lección 5 de 8

Cierre

Captura de requisitos
–
Esta etapa es muy importante para poder entender la necesidad que se presenta y el objetivo para el
cual trabajaremos en el desarrollo de un sistema de información.

Modelo de negocio
–
El modelo de negocio se confecciona a través de UML (Lenguaje Unificado de Modelado).

1. Actor de negocio: representa un rol en relación con el negocio, por algo o alguien en el entorno
del negocio, por ejemplo: clientes, proveedores, autoridades locales, organizaciones, socios,
etcétera.

2. Caso de uso: representa una funcionalidad manejada, requerida o usada por los trabajadores del
negocio, un documento o una parte esencial de un producto, y a veces algo menos tangible como
el conocimiento sobre el mercado o sobre un cliente. Es representado por óvalos y el texto dentro
de estos representa la función del sistema.

Modelo de dominio
–
El modelo de dominio se describe utilizando el diagrama de clases de UML.

Este último especifica clases obtenidas de la especificación de los requisitos. El objeto del modelo del
dominio es comprender y describir las clases más importantes dentro del contexto del sistema.
El diagrama de clases determina las distintas clases con sus interrelaciones, por ejemplo, herencia,
asociación y agregación. Además, las clases poseen atributos que son propiedades de estas.

Las clases están representadas con rectángulos que se dividen en tres partes:

1. Superior: indica el nombre de la clase.

2. Intermedia o central: indica los atributos.

3. Inferior: indica las acciones u operaciones.

Diagrama de caso de uso

–
En esta instancia se modela con UML la funcionalidad del sistema de información a través del modelo
de caso de uso donde podremos evidenciar los procesos que lleva a cabo el sistema de información,
teniendo en cuenta los procesos esenciales, como aquellos que sirven de soporte al sistema y la
relación de los usuarios con cada uno de ellos.

Prototipo de interfaz de usuario

–
Podemos realizar prototipos de interfaz de usuario que nos ayudarán a entender las interacciones entre
los usuarios y el sistema. Para esto, nos basaremos en los casos de uso.

Cuando hacemos referencia a interfaz de usuario para un sistema de información, estamos hablando de
las pantallas, los mensajes, los reportes, etcétera, de dicho sistema.
Lección 6 de 8

Glosario de términos

B
–
Búsqueda: proceso esencial del sistema que comienza con la preselección de postulantes y finaliza
con la definición del candidato que ocupará el puesto laboral solicitado. Existen búsquedas que, por las
características del puesto por cubrir y la rotación constante de empleados en algún puesto o área en
particular, pueden tener un inicio, pero no un cierre; es decir, la búsqueda queda abierta para que los
mismos candidatos que se filtraron en una primera instancia permanezcan como candidatos para ocupar
el mismo puesto en un futuro.

C
–
Candidato: postulante asignado a una búsqueda que se encuentra transitando el proceso de selección.

E
–
Etapas: cada una de las diferentes partes que debe superar un candidato para ser elegido para ocupar
un puesto laboral. Las etapas más comunes son: inicio, entrevista, exámenes médicos, psicotécnico,
etcétera. También pueden crearse etapas según las necesidades de cada búsqueda.

Estado: indica el estado o resultado de una etapa para un candidato en el proceso de selección o
búsqueda en el que está participando. Los estados que puede tomar una etapa son: pendiente (aún no
pasó por esta etapa), apto (pasó la etapa correctamente), no apto (no pasó la etapa correctamente) o
condicional (no pasó la etapa correctamente, pero puede continuar con el proceso de selección).
P
–
Postulante: cualquier persona que haya ingresado su currículum en la base de datos del sistema por
cualquiera de las vías posibles, aun cuando no haya sido seleccionado hasta el momento para ninguna
búsqueda. Al ser seleccionado un postulante para una búsqueda cualquiera, este se convierte en
candidato para dicha búsqueda.

Proceso de selección: desde el punto de vista del individuo, el proceso de selección hace referencia a
la sumatoria de etapas que debe pasar para ser seleccionado para ocupar un puesto laboral y, desde el
punto de vista de la empresa, hace referencia a la sumatoria de todos los procesos de cada candidato
desde que se inicia la búsqueda hasta que se cierra con la selección del candidato o los candidatos
según el caso.
Lección 7 de 8

Referencias

Jacobson, I., Booch, G., Rumbaug, J. (1999). El proceso unificado de desarrollo. Recuperado de
http://www.kybele.etsii.urjc.es/docencia/IS4/2007-2008/Material/ProcesoUnificadoI.pdf

Oviedo, J. (2011). Habilitación profesional.Empresa: Cedi Consulting & Training. Actividad:

consultoría, desarrollo de software, training y venta de licencia de productos informáticos.
Producto: selección de personal (Trabajo final inédito). Universidad Tecnológica Nacional, Córdoba,
Argentina.
Lección 8 de 8

Descargá la lectura

Módulo 2. Disciplina de modelado de negocio y

requerimientos.pdf
1.5 MB

Diseño de Sistemas de Información - Móoulo 2.mp3

7.1 MB