Análisis de Sistema Resumen Nicolás Aguirre

Resumen Análisis de Sistemas

UNIDAD 1: MODELADO DE PROCESOS DE NEGOCIO
Organizaciones y sistemas
Una organización es un grupo formal de personas y otros recursos, materiales, materias primas,
tecnológicos que se constituyen agrupan, relacionan y persiguen un fin. La idea es cumplir con un
conjunto de metas y lograr un resultado que cumpla ese objetivo.
Una organización es como un sistema porque un sistema también es un conjunto de elementos
relacionados que persigue un fin, desde ese aspecto podemos considerar a la organización como un
sistema. Nosotros estamos orientados a un sistema de información.
Un sistema de información es un conjunto de elementos, los cuales conforman un sistema informático,
están interrelacionados entre si y de esa forma persiguen un objetivo común.
Una organización está formada por procesos y esos procesos nos sirven para poder desarrollar y
proponer un sistema de información.
Toda organización necesita una entrada o conjunto de entradas que van a generar que la organización
se ponga en proceso, esas entradas son necesidades, pedidos, eventos que van ocurriendo que hacen
que esta organización se ponga en ejecución y ejecute una serie de procesos, dichos procesos van a
ser una serie de mecanismos de transformación considerando recursos materiales, insumos,
personas, todo aquello que necesite para poder trabajar, ejecutar una transformación y lograr un
resultado: la salida, productos o servicios que estarían cubriendo esas entradas. Todo es cumpliendo
un objetivo, por tanto, este mecanismo de entrada proceso salida actúa para lograr un objetivo y tiene
elementos interrelacionados (los recursos) que permiten la ejecución.
Además, esa organización nunca está aislada, sino que esta dentro de un ambiente o contexto, de los
cuales, el objetivo personal de la organización a su vez intenta satisfacer necesidades de ese entorno.
Y ese mismo ambiente le va a estar dando una devolución (retroalimentación) y de esa forma el ciclo
de entrada-proceso-salida-retroalimentación se vaya ajustando conforme a la retroalimentación para
mantenerse en ese mercado y cumplir las necesidades o expectativas de ese entorno.
Análisis de Sistema Resumen Nicolás Aguirre
Como nosotros queremos desarrollar un sistema de información debemos conocer cómo funciona lo
anterior, debemos encontrar los datos (debido a que manejamos sistemas de información, podemos
usar datos) considerar y reconocer esos datos, para luego generar ese procesamiento, teniendo que
ver las funciones que un sistema informático puede hacer que contemple lo que esa organización
ejecuta en sus tareas y aprender a definir las salidas que será siempre información. Únicamente se
pueden manejar datos e información.
Como estamos siempre dentro de este proceso de entrada-proceso-salida vamos a tener un objetivo,
que será coherente en la búsqueda y en la ayuda de que esa organización cumpla el objetivo y también
siempre todo sistema informático tiene un camino de retroalimentación que permite ajustar los datos
de entrada para que siempre siga sirviendo a los fines para el cual está establecido. Finalmente vamos
a encontrar y desarrollar sistemas de información que sirvan a los distintos niveles de esa organización
que permitan reducir incertidumbre del accionar de las cosas, brindar información en función de los
distintos niveles de la organización teniendo en cuenta las características de cada nivel de la misma y
permitir la toma de decisiones.

Procesos
Los procesos atraviesan las organizaciones, abarcan un concepto más integral, teniendo en cuenta
varias áreas de la organización, y estos procesos permiten transformar las entradas en salidas.
Nuestro foco va a ser identificar estos procesos de negocios, modelarlos y proponer un sistema de
información.
Gestión de procesos
Hubo una nueva forma de trabajar, antes las organizaciones no se veían con toda esta visión o gestión
de procesos, con el tiempo y con la evolución como las organizaciones tenían que mantenerse en un
mercado competitivo y tenían que adaptarse a los cambios que cambio la forma de atención al cliente
y proveer servicios, las organizaciones tuvieron que cambiar esta estructura jerárquica y tradicional a
Análisis de Sistema Resumen Nicolás Aguirre
hacer una forma de mirada que tuviera esta visión o gestión de procesos. En función de eso, teniendo
que incorporar, adaptarse al cambio, mantenerse en un mercado competitivo y agregar las nuevas
tecnologías de comunicación y de información, con todo este avance tecnológico, tuvo que buscar una
manera diferente y de cómo trabajar internamente y buscar realizar una gestión de procesos.
Esta gestión de procesos tiene una nueva visión y lo que busca es que favorezca y facilite a ese
negocio mantenerse en el mercado competitivo, entendiendo por gestión la acción de coordinar todas
las actividades para dirigir y controlar una organización. La gestión cambio la forma en que ejecutaba
y concretaba esa dinámica de la organización.
De allí que nuestra gestión de proceso es como una técnica de gestión, cambio la forma de actuar de
los que dirigían la organización y ayudo a los dueños a que pudieran:
- Identificar los procesos
- Diseñar procesos: establecer, definir la secuencia de los procesos, identificar quienes son los
intervinientes
- Formalizar procesos: quiere decir documentarlos.
- Controlar procesos
- Mejorar procesos: una vez que los tengo definidos, ver cómo puedo mejorarlos
- Lograr que sean más productivos los procesos
Con todo esto lograron la confianza del cliente, dando un producto de valor.
Esta gestión de los procesos promueve
o Agregar valor al cliente: antes la organización estaba más centrada en lograr su objetivo, en
cambio ahora se intenta procurar la satisfacción del cliente
o Trabajar metodológicamente: crear diseños, modelos para poder definir esos procesos
o Incorporar de verdad la calidad y estar más cerca de una certificación en normas de calidad
o Mejorar los procesos en forma continua
o Tener procesos eficientes, eficaces y controlados
o Rediseñar los procesos para obtener mayor rendimiento
o Conocer lo que se hace y como lo hacen para perfeccionarse
En esta gestión de procesos, se agregaron dos grandes conceptos como referentes. Por un lado, lograr
la productividad, pero la idea es aumentar es aumentarla haciendo las tareas de forma eficiente, para
lograr un mejor resultado y que al cliente se le dé un producto de mayor valor. También se agrega el
concepto totalidad, que significa que en vez de ver esas estructuras jerárquicas y las áreas
funcionales tan divididas o seccionadas, la gestión de procesos da una visión integral, amplia y
completa de una situación y todo proceso empieza desde una situación donde hay una necesidad, un
conjunto de acciones, muchos intervinientes de distintas áreas y logran un resultado. La vista de
totalidad aporta un cambio a el análisis y la identificación de los procesos a comparación de antaño.
De esta forma vamos llegando a cuando aplicamos la gestión de procesos, podemos llegar a trabajar
en:
- Describir: conocer actualmente como esa organización lleva a cabo sus tareas, identificamos
todos sus procesos, quienes intervienen y cómo funcionan.
- Mejorar: a ese proceso, con algunos cambios puedo agregarle algo y lo puedo optimizar, lo que
sería una mejora.
Análisis de Sistema Resumen Nicolás Aguirre
- Rediseñar: consiste en buscar un cambio de fondo. Esta más asociado el concepto de
reingeniería que significa replantear la forma en que se hace, los intervinientes y haga una
nueva propuesta de proceso que reformula el que actualmente esta funcionando para que logre
cumplir el objetivo de una forma más óptima.
En esta materia vamos a intentar describir.
Procesos de Negocio: conceptos básicos
Todo lo que se vea a continuación será desde una visión sistémica para que no se pierda el enfoque
de intentar entender algo para desarrollar un sistema información.
Definición de un proceso
Hay una primera definición que dice que un proceso es una totalidad que cumple un objetivo completo,
que es útil a la organización y agrega valor al cliente.
Pero al relacionarla con los negocios, podemos completarla y ampliarla diciendo que un proceso de
negocio es un conjunto de actividades y tareas que están relacionadas lógicamente, en ese conjunto
de actividades que se llevan a cabo vamos a tener una interacción de personas y recursos que se van
utilizando para poder llevar a cabo actividades y tareas. Todo esto va a ser llevado para cumplir un
objetivo, tenemos una finalidad en común que es transformar las entradas en salidas, generando un
producto o servicio que agreguen valor para los clientes.
Visión de procesos
Esta visión de procesos es una forma integradora de varias áreas funcionales, puesto que las atraviesa
transversalmente. Esto quiere decir que un proceso empieza desde una necesidad, va a pasar por un
conjunto de actividades donde van a haber distintos recursos intervinientes, personas con roles,
materiales insumos y demás, continuando ese proceso hasta llegar luego de ejecutar estas actividades
obtener un resultado, productos o servicios, cumpliendo un objetivo.
Un proceso ofrece una versión horizontal de la organización, queriendo decir que cruza
horizontalmente a la organización y da respuesta a un ciclo completo.
Dentro de esta visión de procesos cuando tengamos que identificar un proceso, tendremos que tener
en cuenta el delimitarlo, considerar desde cuando empieza el proceso y hasta cuando termina. Para
los procesos esenciales, desde que se produce contacto con el cliente y establece su necesidad, ahí
arranca el proceso principal y termina cuando, después de haber pasado por un conjunto de
actividades, haber hecho una transformación de entradas y salidas, ejecutado un uso de recursos logra
el resultado, que sería el producto o servicio que ese cliente solicito y que ha recibido
satisfactoriamente.
Un proceso nos ayuda a entender la globalidad de la tarea que se desempeña y ese ciclo completo en
ese proceso de transformación sigue un eje de temporalidad, lo que va ocurriendo es irreversible.
Análisis de Sistema Resumen Nicolás Aguirre
Esquema de procesos
En este nuevo esquema se integra todo lo que se vio anteriormente para definir el proceso de una
organización, con entradas, donde un evento o algún estimulo dispara una necesidad e inicia el
proceso, que será un conjunto de actividades e interacciones donde participan distintos recursos,
humanos, materiales, conocimientos e información y produce un resultado que es una salida,
cumpliendo un objetivo y principalmente se busca agregar valor al cliente como foco de esta visión de
procesos.

Cliente del proceso

Un cliente se va definir como una persona u organización a quien servimos y a quien está destinada
la misión de una organización.
Cuando hayamos identificado nuestro proceso tenemos que poder encontrar un cliente y saber que,
si ese proceso existe, es para agregarle valor a ese cliente.
En general para los procesos que son principales, vamos a encontrar en su mayoría clientes externos,
que son los relacionados directamente con la misión de la organización. Ejemplo: una persona que
realiza un pedido.
Pero también los clientes pueden ser internos, siendo estos, otros procesos que pueden necesitar la
salida que produzca un proceso en cuestión. Un cliente interno es cuando un proceso de una misma
organización requiere de otro proceso.
También aparece otro concepto como stakeholders, que es un grupo de interés que representa a
cualquier otra persona o entidad que es afectada por las actividades de una organización, sistema o
proyecto. Son otras personas interesadas en este proyecto, pero no están involucradas de forma
directa, pero no son el cliente, no tienen esa necesidad, pero a veces nos pueden llegar a crear una
restricción. Ejemplo de estos van a ser los accionistas.
Análisis de Sistema Resumen Nicolás Aguirre
Dueño del proceso
Es aquel que esta dentro de la organización y tiene un rol ejecutivo, es aquel que ha diseñado cual es
el conjunto de pasos que ese proceso comprende, que recursos utiliza, cuales son los involucrados,
los objetivos y el resultado de valor que ese proceso debe tener,
Es un rol ejecutivo a quien se le encomendó velar por el buen desempeño de un proceso completo de
principio a fin. Es la persona responsable de definir ese proceso y que el mismo se cumpla.
Tiene autoridad para modificar el diseño del proceso y monitorear si eso se está ejecutando o no.
Un proceso se puede describir, mejorar o rediseñar. Es el dueño el que describió el proceso
inicialmente, el que lo analiza y puede proponer una mejora para optimizarlo o puede replantear y
hacer un trabajo de reingeniería para que el mismo cumpla correctamente su función.
Busca siempre aumentar la satisfacción del cliente.
Normalmente el dueño audita el proceso, es decir, que lo controla para que se realice tal como está
definido. El dueño defiende la totalidad del proceso de cara al cliente.
Tipos de procesos
Estratégicos
Los estratégicos brindan definiciones de procesos a nivel superior directivo que establezcan
estrategias en la organización. Establecen normativas, instructivos, objetivos operativos, dan un marco
global o visión general que necesita establecer la organización para funcionar.
Son procesos que están orientados a planificar: definir planes estratégicos, la visión o la misión de las
organizaciones; a implementar: son algunos procesos que buscan concretamente que acciones va a
definir y cómo va a accionar y va a funcionar el negocio; a verificar: establecer una serie de procesos
que permita controlar el avance del plan y por otro lado retroalimentar: van a haber en función de cómo
está ejecutando sus tareas qué necesidad hay de ajustar, de incluir un nuevo proceso o mejorar alguno
Esenciales
Se pueden escribir con distintas formas de denominación. También se llaman procesos del negocio,
claves, críticos, Core o procesos principales.
Son aquellos que vamos a encontrar y que atienden a la misión de la empresa y son los que se
relacionan con el cliente. Hacen a la principal acción de la organización y su principal producto, servicio
o proceso.
Estos procesos esenciales o principales son vitales para el funcionamiento del negocio, ejecutan la
acción principal del negocio.
Están asociados a los productos o servicios que presta una organización. En empresas pequeñas hay
entre 1 y 3 procesos esenciales, entre las grandes pueden llegar a 5 o 6 procesos esenciales.
De soporte
Son aquellos procesos que va a ejecutar un conjunto de acciones que son complementarias y
necesarias para que los procesos esenciales se puedan realizar. Sirven de apoyo a estos otros
procesos y contemplan todas las otras actividades necesarias en una organizar para poder realizar
sus funciones.
Análisis de Sistema Resumen Nicolás Aguirre
En empresas pequeñas puede haber hasta 20 y en empresas grandes hasta 200.
Normalmente con algún proceso de soporte es donde van a aparecer estos procesos que van a tener
una necesidad y que otro proceso ejecute una tarea. Cuando tengo varios procesos identificados
dentro de un negocio y un proceso necesita que otro ejecute algo es ahí donde aparece ese concepto
de cliente interno porque tengo dentro de la organización muchos procesos y para que este proceso
funcione necesita realizar o tiene la necesidad de que otro proceso le cumpla y ejecute una
funcionalidad.
Modelado visual de los procesos
Las clasificaciones anteriores pueden representarse mediante diagramas visuales. Los procesos se
representarán en los denominados: “mapas de procesos”.
Hay que antes, saber qué es un modelo, debido a que nos sirve para representar algo y obtener una
vista más simple de lo que queremos expresar o identificar.
Un modelo es una representación simplificada de la realidad, logramos representar en algo grafico esa
realidad que estamos intentando construir o representar. Cuando vamos creando un modelo buscamos
facilitar la compresión y estudio de algo, permitiendo ver de forma más clara y sencilla las distintas
cosas que queremos representar, variables, relaciones o lo que sea necesario según lo que ese
modelo representa.
Nosotros usamos modelos porque son útiles, representan la realidad más fácilmente, porque
simplifican una forma de expresar algo y modelar, porque modelan situaciones reales o que pueden
ser complejas y este modelo lo simplifica.
Existen muchos justificativos para modelar procesos de negocios, por un lado, para conocer cómo
funcionan y por otro, el cual es nuestro fin, crearemos modelos que nos sirvan como base para poder
crear el sistema de información adecuado que soporte ese negocio. Si yo conozco bien cómo funciona
el negocio, quienes son los clientes, que tipos de procesos ejecuta y quienes intervienen voy a poder
proponer un sistema de información y desarrollar un sistema informático que sirva a ese negocio.
Existen otras funciones mas por las cuales podemos modelar procesos d negocios, para mejorar las
operaciones y la estructura del negocio, para mostrar la estructura de ese negocio, para experimentar
con un nuevo concepto de negocio, es decir, buscar la reingeniería y el rediseño y demá[Link] lo más
importante es que modelamos procesos de negocios porque queremos desarrollar un sistema de
información adecuado.
Dentro de lo que es el modelamiento visual de los procesos que es una teoría que propone distintos
diagramas, cuatro al menos en esta nueva forma de entender los procesos, los cuales son: mapa de
procesos, mapa del ámbito, flujograma de información y tareas de la actividad. Nos enfocamos en
mapas de procesos.
Mapa de procesos
Es un diagrama que les va a proveer de una visión, de un mapa que va a mostrar algo general. Vamos
a identificar los procesos según las tres clasificaciones anteriores y los voy a mostrar en un diagrama
con todos los procesos de esa organización.
La simbología para mostrar cada proceso es:
Análisis de Sistema Resumen Nicolás Aguirre

Adentro se va a escribir el nombre del proceso identificado en verbo en infinitivo. Por cada proceso
identificado se establece un objetivo que lo describe.
Describir un proceso
De todos los procesos identificados vamos a tener que hacer una profundización, una mirada interna
y describir los mismos. Tenemos un mapa de procesos con 8 procesos, por tanto a cada uno se lo
analiza con una serie de aspectos que va a analizar y describir.
Lo que se busca describir es:
- Por qué se realiza, cuál es su finalidad
- Quien tiene la necesidad
- Que produce
- Quienes participan en su ejecución
- Como se realizan
- Que recursos utilizan
- Para qué sirve el proceso
Cuando empezamos a describir un proceso, aparte de tener su objetivo y finalidad, tenemos que
pensar quién es el que tiene la necesidad, por lo cual ese proceso empieza en acción, hay un estímulo,
una necesidad que genera que empiece a ejecutarse este proceso. Ese quien tiene un nombre, que
es el cliente.
Siempre que tenemos un proceso debemos encontrar quien es el cliente, y es quien necesita que el
proceso se ejecute, pudiendo ser externo o interno según como sea el cliente.
Producto del proceso
Cuando hablamos de producto del proceso, hablamos del resultado logrado de ejecutar ese conjunto
actividades y que cumpla con el objetivo de ese proceso luego de aplicar las transformaciones
necesarias a las entradas y con el uso de los recursos necesarios.
Proveedores e insumos de un proceso
Cuando vamos pensando en el proceso y su conjunto de actividades, puede ser que haya una
necesidad de algo o de alguien que me colabore o me provea de algo para que pueda continuar con
una siguiente acción, eso va a ser el concepto de un proveedor del proceso. Son aquellos que
colaboran con el proceso que estamos describiendo, nos tenemos que parar en el proceso que
analizamos y pensar quien nos ayuda en el mismo.
Análisis de Sistema Resumen Nicolás Aguirre
Proveen de algo necesario para la realización de dicho proceso y van interviniendo y colaborando para
la concreción del mismo. De alguna forma participan en el proceso con esta funcion de proveer algo,
de allí el nombre de proveedores.
Cuando los identificamos podemos llegar a encontrar
- Entidades externas que no pertenecen a la organización
- Personas o roles / funciones externas que tienen esta participación
- Otros procesos internos (dentro de la organización)
El insumo es todo aquello que se provee como ingreso para el proceso para colaborar con la
realización del mismo, debemos entonces identificar el proveedor y los insumos que ese proveedor
brinda. Ese insumo va a ser necesario, se va a consumir en el conjunto de tareas que ejecuta ese
proceso
Un insumo puede ser información, materiales, materias primas, conocimiento, cualquier cosa que me
provea de algo para ejecutar la tarea.
La relación entre proveedor e insumo es que el proveedor provee y el insumo es aquello que se
proveyó.
Recursos del proceso
Son todos los elementos necesarios para realizar un proceso, esos recursos participan del proceso,
colaboran con la ejecución de las distintas actividades. Si son personas, son las que participan y
colaboran, otros recursos son consumidos y también con los recursos hago la transformación de las
entradas en salidas. Voy utilizando los insumos provistos y todos estos elementos son utilizados para
cumplir con el objetivo del proceso.
Cuando nosotros describimos un proceso nos centramos en dos tipos de procesos que son los únicos
que nos sirven para luego encontrar y derivar el sistema de información. Nos vamos a concentrar en
recursos humanos que son todas las personas con sus roles que participan en el proceso y recursos
tecnológicos debido a que estamos modelando procesos de negocios y los estamos describiendo para
conocer cómo funciona y luego proponer un sistema de información que sirva a ese negocio.
Formularios, registros e información
Cuando vamos pensando un proceso es importante definir todos los documentos que maneja y toda
la información que registra, almacena, consulta. Por un lado, vamos a identificar los formularios, que
serían todos los documentos formales, informes y reportes, estadísticos o que hagan un balance que
este proceso utiliza. Ya sea que lo recepta porque viene de afuera, o que lo genere o lo esté
almacenando y lo consulte. Ejemplo de formulario puede ser: remito, orden de compra, recibo de
sueldo, nómina de empleados. Por otro lado, tenemos que identificar toda la información y los
registros que ese proceso ejecuta, lleva a cabo y consulta. Es toda información que se procesa, puede
ser que ingresa y hacen proceso, que hacen calculo, que almacene, y si ya está almacenada que
consulte o si genero un documento a la vez genera nueva información de ese documento que está
generando. Deberemos poder informar todo registro e información, ejemplo: pedidos, clientes, pagos
a proveedores, empleados, sueldos, servicios, artículos.
Reglas de negocio
Va a ser el conjunto de políticas, normativas y lineamientos definida de forma interna por el negocio
para este proceso o para el proceso que se describe.
Análisis de Sistema Resumen Nicolás Aguirre
Describe normativas y comportamientos del modo de trabajar del negocio, refiere a aspectos internos,
porque las reglas de negocio se las define desde la organización o negocio y va a establecer las
políticas del mismo, mediante un conjunto de sentencias que definen y especifican algunas líneas o
formas de trabajo del negocio. También van a representar conocimiento del negocio
De esta forma, estas reglas de negocio gobiernan como el negocio debería ejecutar sus tareas, como
administra sus recursos o como se relaciona con otros. Una regla de negocio termina restringiendo el
negocio porque dice que puedo hacer y qué no.
Restricciones
Van a ser todas esas normativas, leyes o exigencias externas establecidas por organismos
reguladores, convenios externos o acuerdos que de alguna forma me restringen también el proceso,
pero acá la diferencia es que esta restricción está definida en forma externa, una restricción es una
limitación, pero siempre viene de afuera, a diferencia de la regla del negocio que es algo interno.
Cuando describimos un proceso, no se ejecuta libremente, siempre tiene limitaciones, para todas
aquellas definiciones internas, vamos a poner bajo el título de reglas de negocio todas las políticas y
lineamientos que restringen el proceso y para todo aquello definido externamente bajo el título de
restricciones vamos a poner todo lo que nos regula o también me restringa el proceso. Ambos
restringen, pero las internas van a reglas de negocios y las externas van a restricciones.
Actividad
Conjunto de acciones que alguien realiza con un rol ([Link].) en un periodo de tiempo específico y
controlado y ejecuta y realiza una secuencia de acciones para lograr cumplir con un objetivo y
completar con toda la actividad que un proceso lleva a cabo. Está compuesta por tareas que son parte
del flujo de proceso, entendiendo que la tarea se lea como una especificación o detalle de una
actividad. Se va a plantear como una lista secuencial, con una secuencia lógica de ocurrencia con
verbos en infinitivo y se van describiendo todas las acciones que ese proceso tiene en cuenta para
poder cumplir con el objetivo.
Actividad – Excepciones
Hay cosas que están relacionadas con ese proceso, pero no tienen espacio en esa secuencia de
acciones y que en algún lado se deben indicar. Son esas que entran en este concepto de excepciones,
es todo aquello que consideremos como alguna situación que sucede en el negocio que no sigue el
camino normal (el conjunto de acciones normales que se ejecutan) están relacionadas a situaciones
de la anulación o cancelaciones o todo aquella que venga a posteriori del inicio del proceso y no está
considerada en esa secuencia, por tanto, debe identificarse y enunciarse en el espacio de
excepciones. Se le da un nombre y una descripción (breve).
Modelado de procesos con BPMN
Qué es BPM
Significa Bussiness Process Mangement – Gestion de procesos de negocio.
Esto que porpone es una metodología donde lo que vimos de la gestión de procesos hasta ahora está
ordenado y establecido como una serie de actividades y una serie de definiciones todos en búsqueda
de una mejora continua de como esa organización funciona, de mantenerse en el mercado y optimizar
sus procesos de negocio. BPMN es una metodología empresarial cuyo objetivo es mejorar la eficiencia
en esa organización, a través de la gestión de los procesos de negocio que los mismos se deben
Análisis de Sistema Resumen Nicolás Aguirre
modelar, organizar, documentar y optimizar de forma continua. En este concepto de modelar es donde
aparece la notación para poder representar los procesos del mapa global o mapa de procesos y
organizar y documentar sería parte de esta descripción del proceso y la idea de la optimización es que
siempre para poderse mantener con procesos definidos y estar en el mercado competitivo los procesos
deben estar optimizados de manera continua.
BPM utiliza metodológicamente un ciclo de vida para poder ir evolucionando y mantener en el mercado
a cada una de esas organizaciones. Esa búsqueda de mejora continua está enfocada en que los
procesos aporten valor al cliente y también al negocio para poder concretar y cumplir con los objetivos
estratégicos con los que este la organización y con todos los indicadores de negocio definidos en todo
lo que significan esas estrategias y planificación estratégica de una organización.
A BPM le vamos a agregar una N, transformándolo en BPMN
BPMN
Busines Process Modeling Notation – Notación para el modelado de Procesos de Negocio
Es una notación grafica estandarizada, queriendo lograr con la estandarización es que todas las
personas que modelen un proceso con la metodología estandarizada van a poder leer ese diagrama
de la misma forma, porque cada símbolo tiene una representación ya estandarizada, y todo esto
permite el modelado de procesos de negocio.
Esta notación fue creada en 2001 por BPMI, siendo esta absorbida por OMG en el año 2005.
La finalidad de tener una notación estandarizada es que proporcionen un lenguaje común para que
todas las partes involucradas (las partes de los analistas de procesos y el equipo del lado del negocio
u organización) puedan entender y comunicar los procesos de la misma forma o con la misma lectura.
Vamos a poder representar los procesos de forma clara, completa y eficiente, a través de la definición
de una notación y una semántica para modelo de procesos de negocio.
El modelado de procesos con BPMN permite representar:
• Una gran cantidad de niveles de detalle, en diferentes diagramas.
• Está destinada para dar soporte únicamente a aquellos procesos que sean aplicables a
procesos de negocio. No sirve para procesos más allá de este contexto.
Aspectos de un buen modelo
• Selectivo: hay que seleccionar lo que sea significativo o relevante, detalle de mas no aporta y
algo muy global no sirve.
• Exacto: debe reflejar la realidad tal cual es, no debe acarrear errores o modelar algo incorrecto
• Cuidadosamente completo: cuando voy representando debo construir un modelo simple
selectivo, solo de elementos significativos, pero no puede estar incompleto.
• Comprensible: tenemos que usar la representación y la gráfica necesaria para que ese modelo
que estamos representando sea fácil de leer y de comprender.
Análisis de Sistema Resumen Nicolás Aguirre
Notación y simbología del BPMN
Eventos
Va a ser algo que ocurre y lo voy a tener que representar y que puede estar en el inicio, durante o al
final del proceso. Es todo aquello que pueda ocurrir durante el transcurso de un proceso, la simbología
que lo representa es un circulo.

Al menos por proceso habrá un evento de inicio (el disparador de todo) y un evento de fin (que es el
fin de todo) puede llegar a surgir eventos intermedios y otros eventos de fin en función de lo que el
proceso está comprendido.
Por cada evento que se detecta se rotula, se le va a dar un nombre, que va a tener lo más breve
posible pero clara y completa de lo que está representando ese evento en esa parte del proceso. Se
redacta como una oración o frase sustantiva.
Eventos de inicio: representa cuando un proceso inicia, no tiene flujos de secuencia (una flecha de
ingreso) entrantes debido a que es el primer símbolo que vamos a graficar cuando empecemos con la
graficación del proceso.
Análisis de Sistema Resumen Nicolás Aguirre
Eventos intermedios: cuando vamos creando el proceso y en conjunto con los otros elementos puede
ser necesario que se necesite modelar algo que puede ocurrir durante el transcurso de proceso que
sea la espera de un tiempo, la espera de una situación, la llegada de una información, la generación
de otra el paso del tiempo en algo, es donde vamos a necesitar utilizar esta notación que son los
eventos intermedios. Indican algo que ocurre o puede ocurrir durante el transcurso de un proceso entre
el inicio y el fin. Los eventos intermedios pueden utilizarse dentro del flujo de secuencia o adjunto a los
límites de una actividad.

Eventos de fin: el evento de fin es cuando estamos modelando el camino y el proceso finaliza, siendo
con éxito si se cumplió el objetivo. Al menos siempre tenemos un evento de fin, pero todo evento de
fin representa el final de un camino. Podemos tener varios momentos donde el proceso se interrumpe
a partir de alguna situación o condición validada y no se puede continuar. Indican cuando un camino
del proceso finaliza. No tiene flujos de secuencia saliendo del mismo (a partir de ahí no hay más flechas
que salgan de el). La frase indica e estado final al que arribo el proceso (el rotulo).

Objetos de conexión
Conectan distintos elementos en el diagrama, pudiéndose identificar:
Análisis de Sistema Resumen Nicolás Aguirre
Secuencias: es lo que más vamos a usar para poder conectar los distintos elementos que vamos
graficando de un diagrama. Está representado por una flecha y representa como la secuencia de
acciones de un evento de inicio con otro elemento, cual es la actividad que sigue y que otros elementos
continúan en esa secuencia, la punta de la flecha indica que secuencia va a ocurrir. Las secuencias
representan el control de flujo y la secuencia de las actividades. Se utiliza para representar la
secuencia de los objetos de flujo, donde encontramos las actividades, las compuertas y los eventos,
relacionando dos elementos de este tipo.

Asociaciones: dependerá en función de lo que vayamos modelando y otros elementos que necesitan
relacionar. Se usan para asociar información adicional sobre el proceso, de allí que como es
información adicional, si necesitamos agregar una nota, una conexión, alguna cosa especial la
usamos, sino no. Van conectados a algún elemento representado en el proceso, pueden ser artefactos

Actividades
Representa el trabajo realizado dentro de una organización, las acciones realizadas para ejecutar las
tareas involucradas en el proceso. Lo que no hay es una correspondencia tan exacta entre la cantidad
de actividades anotadas y los cuadros que tendré que dibujar, a veces una secuencia de actividades
puedo desglosarla, o capaz dos actividades pueden integrarse en un solo cuadra. Se corresponde la
secuencia lógica, pero no la cantidad de cuadros y actividades.
Consumen recursos las actividades, y una actividad puede ser simple (tarea o mejor dicho atómico
porque no puede desglosarse) o compuesta (subprocesos).

Tipos de tareas
Especifican la naturaleza de la tarea que se desea llevar a cabo, pueden ser:
- Usuario: esas tareas involucran que en algún momento esa persona use un software
- Manual: no involucra en absoluto el uso de software
Análisis de Sistema Resumen Nicolás Aguirre
- Servicio: sirven para modelar transacciones en línea de
procesos que son absolutamente automáticos, donde existe
uno o más carriles para modelar el sistema.

Marcador de actividad
Dentro de las actividades que vamos identificando vamos a tener algunas que tienen un
comportamiento particular, usando un par de símbolos para indicar este actividad con esta situación
particular.
Análisis de Sistema Resumen Nicolás Aguirre
Ciclo: dentro de una actividad que vamos haciendo, si esa actividad se va a realizar varias veces, se
le agrega el símbolo de ciclo.
Subproceso: es un tipo de actividad que se llama actividad compuesta, lo que significa que es como
una descripción de un proceso a un nivel intermedio, que si yo voy a un nivel más abajo podré
explotarlo y encontrar más detalles, está conformado por un conjunto más de otros elementos. Puede
tener más detalles y ser desglosada.
Compuertas
Son aquellos elementos que nos van a servir para mostrar distintos caminos, ya sea de apertura, que
se llaman de divergencia o de confluir que se llama convergencia.
La divergencia significa cuando se inician dos o más caminos en el flujo que se está representando y
la convergencia es cuando confluyen dos o más caminos para continuar con una misma actividad.
Siempre las compuertas nos van a servir para marcar distintos caminos en función del proceso que
estemos modelando y esos caminos o rutas pueden ser alternativas (ir hacia un lado u otro) o también
pueden ser paralelas (ejecuto una serie de tareas y luego continuo).
Análisis de Sistema Resumen Nicolás Aguirre

Swinlanes (canales)
Es como un marco del proceso que tiene tres partes, hay una primera línea donde va el nombre del
proceso que estamos representando, luego se tienen los canales o carriles donde en la primera parte
va el nombre del participante o rol y luego un recuadro donde se efectúa el modelado del proceso
utilizando los símbolos mostrados con anterioridad.
Hay tantas líneas o carriles como recursos hayamos identificado que realizan procesos.
Análisis de Sistema Resumen Nicolás Aguirre
Artefactos
Son elementos complementarios, opcionales
Anotaciones: son como comentarios, aclaraciones o notas que terminan de completar alguna cuestión
de estos diagramas que representan para mostrar información adicional sobre el proceso. Son como
cuadros de nota con aclaraciones.

Objeto de datos: permiten mostrar la información que una actividad necesita como las entradas o las
salidas y permite:

Otras consideraciones para realización del diagrama de procesos de negocio

Niveles de granularidad
Me van a servir para manejar la complejidad del proceso y hacen referencia al nivel de detalle del
mismo. Si el proceso es muy complejo, puedo hacer un solo nivel, pero sería un diagrama grande (5
o mas carriles) y que la cantidad de secuencia de actividades que tengo que modelar es amplísima.
Para esos casos usamos:
Análisis de Sistema Resumen Nicolás Aguirre
Nivel descriptivo: es el más general
Nivel operativo: es el que tiene mayor detalle.
Nivel descriptivo
Es un modelo que me describe como la lógica macro del negocio de una forma más compacta, más
sencilla. Yo describo el alcance general de los procesos de principio a fin, la idea es que estén todos
los carriles como subprocesos, algo que se puede explotar y ampliar.

Logra en forma macro y global, una vista rápida de todo lo que hace el proceso y entiendo en forma
general la secuencia
Análisis de Sistema Resumen Nicolás Aguirre
Nivel operativo
Va al detalle para conocer el conjunto de actividades que se realiza exactamente. Va a agregar todo
el detalle que ese proceso lleva a cabo. Con variaciones, controles, con todas las reglas de negocio
identificadas, con interacción de cada participante y de cada recurso humano y con el uso de toda la
simbología necesaria para modelar como se ejecuta el proceso.
Análisis de Sistema Resumen Nicolás Aguirre
UNIDAD 2: SISTEMAS DE INFORMACION Y PROCESOS DE DESARROLLO DE SISTEMAS DE
INFORMACION Y SISTEMAS DE SOFTWARE
Los sistemas de información y las organizaciones
Nuestras bases son las organizaciones, teniendo distintas dimensiones, pero independientemente de
que tan grande o pequeña tienen una estructura organizativa y tiene una serie de actividades que
desarrolla en forma general, independiente que sea de productos o servicios. De esta forma toda
organización tiene que tener sus recursos humanos y financieros, hacer todo lo que es la parte de
gestión contable, comercializar sus productos o servicios, realizar la fabricación del producto, o la
concreción de brindar ese servicio, en función de lo que sea su finalidad, también la gestión de hacer
comprar de los distintos insumos de materias primas o materiales necesarios para las actividades de
la organización y todo esto para poder controlar o dirigir el accionar de la organización.
De esta forma la información es un factor crítico para el éxito o fracaso de un negocio. Nosotros vamos
a encontrar la información que necesita ese negocio, de esta forma vamos a definir: como se produce
esa información, como se distribuye, como almacenarla, como brindar seguridad en los datos que
vamos obteniendo y permitir que se mantenga íntegramente toda la información que esa organización
necesita.
En función de lo anterior deriva que vamos a tener que desarrollar un sistema de información que
brinde información exacta, precisa, oportuna, que tenga calidad y nunca perder de vista que todo lo
que significa administrar información siempre existen una serie de costos asociados y a la vez una
información brindada de forma adecuada y oportuna va a generar mejoras y va a lograr una gestión
eficiente de las tareas de esa organización.
De esta forma los sistemas de información se desarrollan para permitir entonces la gestión y
administración de toda la información necesaria que maneja esa organización y va a permitir el correcto
desarrollo de esas actividades.
La idea de un sistema de información es que brinde un sistema de información que sirva para ayudar
a tomar decisiones, aumentar el conocimiento y reducir la incertidumbre.
Los sistemas de información
Hay una definición de sistema de información que es que siempre un sistema de información es un
conjunto de elementos que están interrelacionados y que permiten recolectar datos en la entrada,
procesar, manipular esos datos de entrada y lograr una salida distribuyendo datos e información para
distintos niveles de organización para proveer un mecanismo de retroalimentación para cumplir un
objetivo.
Análisis de Sistema Resumen Nicolás Aguirre

Toda organización tiene un sistema de información, el mismo puede ser manual o computarizado. Si
es manual nos referimos a que todo el procesamiento de esa información se hace totalmente manual,
no está la ayuda de un sistema informático. Podemos tener pequeñas empresas que, para sus
actividades, todo este accionar es totalmente manual, hay recursos humanos que ejecutan roles o
actividades, pero su registro de información o almacenamiento de información es totalmente manual.
La otra definición o clasificación es el sistema de información computarizado o los distintos nombres
que puede tener como sistema información, sistema de información basado en computadoras o
sistema de información automatizado. Cualquiera sea el nombre, nos estamos refiriendo a un tipo de
sistemas que para el procesamiento y tratamiento de toda la gestión de los datos y la información usan
alguna tecnología informática para administrar esos datos.
Vamos a ahondar en los conceptos siguientes:
La entrada, siempre va a estar considerada en el concepto de aquella actividad que consiste en
recopilar, capturar los datos primarios que ingresan al sistema. Siempre que debamos desarrollar un
sistema informático tendremos que pensar si el ingreso puede ser manual significando que tendríamos
un apersona colaborando en el ingreso de datos, a través de un teclado por ejemplo o si el ingreso de
esos datos puede ser automático (a través de un dispositivo) como un lector de código de barras.
El procesamiento, es lo que se da cuando definimos las entradas es la definición de todas las acciones
que ese proceso va a realizar como conversión de datos, transformación, almacenamiento, cálculos,
ejecutar comparaciones, consultar información y hacer un nuevo cálculo y registrar el resultado, todo
lo que signifique el procesamiento completo con las funciones que tengo que realizar de ese sistema,
cada vez que pensemos un sistema tendremos que pensar ese procesamiento, que va íntimamente
ligado con el almacenamiento, toda información se puede consultar de algún lugar donde está
guardado.
Cuando estamos en el espacio de pensar un sistema con sus procesos vamos a tener que pensar
tanto en sus funciones como en cómo serán almacenados, consultados y registrados sus datos.
La salida, luego de ejecutar el proceso se piensa cuáles son las salidas para brindar información que
le sirva a la organización. Las salidas son el resultado que se obtiene de realizar el procesamiento de
entrada de datos, de utilizar los almacenamientos, de generar nueva información, de procesarla y
obtener un resultado que cumpla el objetivo del sistema.
De esa salida, además de ver cuáles son los resultados que queremos obtener, tenemos que pensar
de qué dispositivo van a salir esas salidas y en que formatos van a ser ejecutadas.
La retroalimentación, es las salidas que se va a utilizar como un feedback, una devolución para saber
que ajustes, que adaptación o que cambios debo realizar en las actividades, en los datos de entrada
y almacenamiento para que eso funcione de manera correcta.
La presencia de errores o problemas sería un claro ejemplo de una retroalimentación que nos va a
servir para corregir lo que esto nos esté devolviendo.
Componentes de un sistema informático
Tiene cinco elementos y un sexto que es transversal y complementario.
Análisis de Sistema Resumen Nicolás Aguirre

Siendo la definición de cada uno de ellos:

Análisis de Sistema Resumen Nicolás Aguirre

Con todo lo anterior se puede establecer una nueva definición de sistema de información, donde le
agregamos más elementos a la misma.
Un sistema de información es un conjunto formal de procesos, en función de cumplir un objetivo,
operando sobre una colección de datos estructurado (Definición de datos que ingresan y están
estructurados), ese ingreso de datos está basado según necesidades de la empresa y los datos se
recopilan, se procesan y se distribuye la información necesaria para los distintos niveles de la
organización según las operaciones de la empresa y las actividades de dirección y control
correspondiente para desempeñar su actividad de negocio.
Tipos de sistemas de información
Sistema de procesamiento de transacciones (TPS)
Las transacciones son operaciones de negocios básicas, este concepto hace a la clasificación de este
tipo. Todas las organizaciones ejecutan tareas rutinarias, esas serían las que vamos a entender como
las transacciones y siempre ese tipo de transacciones se realizan en el nivel operativo donde se
ejecutan todas las tareas.
Si vamos viendo, todas aquellas rutinarias serían las
transacciones de la empresa según su finalidad.
Son sistemas que atienden a capturar y procesar los
datos con el detalle necesario y ejecutar todas las
tareas y actualizaciones y consulta de datos acerca de
las operaciones esenciales de ese negocio y esa
organización. Soportan operaciones rutinarias y
diarias de una organización, funcionan con gran
cantidad de datos de entrada y salida y estos sistemas
sirven como cimiento para los otros tipos de sistemas. Atienden a procesos de soporte.
Análisis de Sistema Resumen Nicolás Aguirre
Tiene una serie de ventajas:
La automatización de todas esas tareas operativas y rutinarias que al ser llevadas a un sistema de
información se optimizan las mismas y los datos capturados y procesados no tienen errores, buscando
asegurar la integridad de los datos y la exactitud de los mismos. Este procesamiento permite por otro
lado, como son tareas operativas, rutinarias y con mucho volumen de datos permite ejecutar todo ese
volumen de datos ejecutándolo más rápido porque si yo logro con dispositivos capturar los datos no
es lo mismo andar registrando a mano y a la vez todo lo que yo tenga manual si no lo ingreso a un
sistema, cada vez que lo quiera consultar no hay ninguna optimización y es todo lento. Todo lo anterior
busca que ese sistema sea fiable, que logre una respuesta rápida y capturar y almacenar una gran
cantidad de datos, todo en búsqueda de ayudar a mejorar el servicio al cliente.
Sistemas de información Administrativa (MIS) o Sistema de Información para la Gestión (SIG)
Este tipo de sistema está conformado por justamente los distintos componentes, personas
procedimientos bases de datos dispositivos, pero es diferente porque va a generar información que
permita la toma de decisiones, para ayudar a lograr una meta organizacional, o sea, ejecuta resultados
que brinda información que permita tomar decisiones a corto plazo, por eso este sistema se dedica a
proporcionar a los directivos de distintos niveles (táctico) y que ayuda a tomar las decisiones en función
de la información que se provee y tomando de donde puede sacar estos informes y elaborar algo para
la toma de decisiones, se va a alimentar del procesamiento de transacciones.
Quien provee la información para generar estos informes es el sistema de procesamiento de
transacciones, ese sistema captura todos los datos.
Dentro de este tipo, parte de los sistemas de procesamiento de transacciones y esos datos les sirve
para generar datos que les sirva para las tomas de decisiones. Colabora a la categoría de decisiones
estructuradas que se realizan regularmente con procesos bien definidos y en las que se sabe a priori
que información es necesaria para decidir. El sistema se va a alimentar de los datos que fueron cargas
por las transacciones de un sistema transaccional y va a generar información estructura, algo que ya
esté definido, predeterminado y que todas las veces se hace de esa forma.
Sistemas de soporte de decisiones (DSS)
También va a alimentar y consumir información de los sistemas transaccionales, pero va a dar soporte
o información que sirva para las decisiones que están dentro del grupo que se llaman poco
estructuradas. No existen métodos claro para tomarlas, tampoco es posible identificar con anticipación
los factores a considerar. Yo puedo diseñar una consulta o informe pero que sea dinámico, eligiendo
variables distintas cada vez, porque se necesita analizar un aspecto que no se analiza cotidianamente
y se necesita tomar decisiones sobre eso.
En este tipo de sistemas son sistemas de procesamiento con datos interactivos que normalmente
ofrecen visualización gráfica, como recortes estadísticos, pero con formatos gráficos para poder
ayudar a ese tipo de decisiones.
La idea es que lo que se diseñe se pueda adaptar a cualquier nivel de gestión estratégico o táctico,
que la forma de uso sea sencilla, debe permitir que ese usuario acceda a información en un formato
familiar en la que el administra la información para su toma de decisiones y le permite ofrecer asistencia
inmediata para resolver problemas complejos, contrastando con el anterior que resolvía decisiones
estructurales.
Análisis de Sistema Resumen Nicolás Aguirre
Sistemas de soporte Ejecutivo (ESS)
También se basa en decisiones poco estructuradas y se alimenta del sistema de información de
transacciones, pero cuando tenemos este tipo de sistema, el mismo está dirigido a los más altos
niveles de la organización.
Sistema de Gestión del conocimiento (KWS)
Son aquellos que van a ayudar o a apoyar a los trabajadores de conocimiento (aquellos que están en
la creación de nuevos productos, diseños, prototipos) y que necesitan un sistema que soporte este
tipo de conocimiento y un software que les de apoyo.
Se usa mucho en lo que es modelado y simulación.
Ayudan a los administradores y trabajadores a
analizar problemas, visualizar aspectos complejos
y a la creación de nuevos productos.
Normalmente dentro de sus datos de entrada va a
haber una base de conocimiento, un diseño de un
nuevo modelo, un nuevo prototipo. El
procesamiento se va a basar en ejecutar una serie
de tareas que hagan el modelado de algo o una
simulación y la salida serán modelos y gráficos.
Un sistema de conocimiento mejora la experiencia
de los empleados y ahorra tiempos de capacitación
porque colabora con lo que es la simulación o
probar con prototipos algunas series de cosas
antes de que se implemente en forma concreta en
una organización.
Inteligencia artificial y sistemas expertos
Son sistemas muy específicos y están
orientados a situaciones que permita
automatizar que tiene características
propias de la inteligencia humana, de ahí
que le llaman sistemas expertos o
inteligentes. Este tipo de sistemas
incorporan en ese software la inteligencia
que una persona decidiría para hacer
algo. Muchos ejemplos de esto son los
que estén relacionado con la robótica y
demás.
A la derecha se ve un gráfico donde coloca
a cada sistema de información con el nivel
operativo al que sirve. Se excluye a los
sistemas expertos.
Cada organización va a realizar sus actividades y tiene que tomar decisiones y en ese manejo necesita
como recurso principal la información. Cuando nosotros nos encontramos con estas realidades
Análisis de Sistema Resumen Nicolás Aguirre
tendremos que realizar una propuesta de información encontrando las entradas y definiendo los
dispositivos, encontrando el procesamiento que vamos a realizar, el almacenamiento vamos a
administrar, que salidas vamos a tener. En esta búsqueda y definición la idea es obtener y lograr un
resultado de información que sirva para tomar decisiones, aumentar el conocimiento y reducir la
incertidumbre. La idea del sistema de información es que permitan la gestión y administración de la
información que le permita a la organización lograr un correcto funcionamiento.
E-commerce Sistema de comercio electrónico
Consiste en ofrecer plataformas o sistemas donde puedan ofrecer las empresas sus productos de
forma online.
M-commerce – Mobile Commerce
Son todas las aplicaciones de celular que posibilitan la venta y compra online de productos.
Requerimientos
Nuestro inicio para desarrollar un sistema es encontrar requerimientos, el qué se necesita para saber
que voy a proponer. Un requerimiento en su definición es una característica de sistema, una
descripción de algo que el sistema es capaz de hacer considerando las restricciones y servicios que
el mismo debe considerar con el objeto de satisfacer el propósito del mismo. Concretamente en
necesidades de alguien (una organización) o algo (una necesidad en el mercado) que requiere que un
sistema informático desarrolle y cubra y ofrezca una serie de servicios y considere las restricciones
del mismo.
Tipos de requerimientos
Requerimientos funcionales
Lo funcional refiere a todo lo que el sistema debe hacer, todo el conjunto de acciones o funcionalidades
que el sistema sea capaz de realizar. Otra forma de decirlo son los servicios que el sistema provea,
detallando las transformaciones que el sistema realiza sobre las entradas para producir salidas.
Atienden a los servicios o lo que debe hacer el sistema según las funciones que debe cubrir.
Por un lado, va a ser un listado de requerimientos que se escriben en verbos en infinitivos y siempre
se usan acciones que estén dentro de lo que el sistema pueda utilizar. Dentro de este planteo se
establecen requerimientos funcionales globales (en una forma general) y luego por cada uno de esos
globales requerimientos funcionales detallados.

.
Análisis de Sistema Resumen Nicolás Aguirre
Encontrando requerimientos funcionales desde el modelo de negocio
Cuando modelamos el BPMN definimos actividades, dándole un nombre y el tipo de tarea. Desde el
vamos, esas actividades según el tipo de tarea ya es un indicador a futuro de qué funciones tendrá el
sistema.

También se analizan las excepciones identificadas en la ficha de proceso.

Requerimientos no funcionales
Los servicios son los requerimientos funcionales, las restricciones son los requerimientos no
funcionales. Siempre que desarrollemos un sistema, el mismo va a tener una serie de limitaciones o
lineamientos establecidos o configuraciones o diseños establecidos o predeterminados o aspectos de
implementación o normativos, aspectos de arquitectura, todo eso estaría en este conjunto de
requerimiento no funcionales. Van a ser esas restricciones a los servicios o las funciones que de alguna
forma limita la elección de alternativas en la etapa del desarrollo. Estas características atienden
aspectos de rendimiento, interfaz de usuario, mantenimiento, todo lo que sean leyes, normativas,
cuestiones de hardware, etc. Se enuncian como una oración narrativa.
Análisis de Sistema Resumen Nicolás Aguirre

Ingeniería de Software
La ingeniería de software está formada por un proceso más un conjunto de método, prácticas y
modelos que permita a los profesionales de sistemas elaborar software para que funcione en
computadoras y que logre una alta calidad, el concepto de calidad acompaña al proceso de ingeniería
de software.
Debemos identificar quien participa en este proceso, por qué es importante, cuales son los pasos que
vamos a ejecutar para lograr ese resultado y hacia dónde vamos, cual es el producto final que
queremos obtener. La ingeniería de software cubre todos esos aspectos.
Existe otra definición que dice que la ingeniería de software es el establecimiento y uso de los principios
solidos de la ingeniería para obtener un resultado que sea un software confiable y con buen resultado
económico y que funcione de modo eficiente en máquinas reales.
Tiene una serie de objetivos, los cuales son por un lado definir una disciplina para garantizar
producción y mantenimiento de un sistema siempre en búsqueda de que mejore la calidad, de que
aumente la productividad a esa organización, le facilite el control y por otro lado facilite las bases para
su construcción.
La ingeniería de software es una disciplina formada por ese conjunto de métodos, herramientas y
técnicas. Nosotros como profesionales tendremos una serie de elementos, de modelos a construir,
una serie de prácticas y actividades para poder lograr el resultado que es un desarrollo de software.
La definición formal, brindada por la IEEE establece que “La ingeniería de software es la aplicación de
un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento del
software, es decir, la aplicación de la ingeniería al software.”
Capas de la ingeniería de software
La ingeniria de software es una tecnología multicapas estratificada, es decir, que tenemos varias capas
en distintos estratos,
Análisis de Sistema Resumen Nicolás Aguirre

Tenemos en la base un enfoque de calidad, quiere decir que todo desarrollo de software hay un
compromiso o búsqueda de obtener calidad en lo que se busca. Además, vamos a ejecutar procesos
que es un marco de trabajo que va a ayudar a todos los que trabajan en el proyecto a organizar cuales
son las actividades para desarrollarlo y el control y la gestión de cómo va avanzando ese proyecto.
Vamos a contar con un conjunto de métodos que son las actividades técnicas, la construcción de
modelos, para poder construir el sistema. Y nos valdremos de una serie de herramientas, que significa
en este contexto que son automatizada o semi automatizadas para colaborar con la construcción de
modelos, aplicar los métodos y llevar a cabo los procesos.
Enfoque de calidad
El tema de calidad es un tema que se incorporó hace muchísimos años que el desarrollo debe estar
orientado a un resultado que tenga calidad, los cimientos que conforma la base de la ingeniería de
software están orientados hacia la calidad. Todo enfoque de ingeniería, todo desarrollo de un sistema
informático busca siempre obtener la calidad en el desarrollo de dicho sistema y aplicando las mejores
técnicas para este desarrollo. En esto incorporamos las normas ISO, que son un conjunto de reglas y
estándares que, si una organización las cumple, estarían certificadas por los organismos detrás de
esas normativas.
Las normas ISO definen a la calidad como el grado obtenido en donde un conjunto de características
inherentes al tema que se está desarrollando cumplen con las necesidades o expectativas que pueden
ser implícitas u obligatorias. Concretamente nosotros vamos a indagar que necesita el cliente,
establecer los requerimientos y entonces ese cliente busca un resultado que es el producto o servicio
que satisfaga sus expectativas (requerimientos) y esa satisfacción está atendiendo cuestiones del
producto, costo, tiempo de entrega, el servicio como cubre esa necesidad y el funcionamiento del
mismo. EL termino de calidad aplica a cualquier desarrollo de producir un bien o servicio y está
Análisis de Sistema Resumen Nicolás Aguirre
adaptado para lo que es el desarrollo de un sistema informático y como cubre con esas necesidades
y de esa forma califica o certifica que está hecho con calidad, o por debajo de los estándares.
El tema de calidad está en la base de la ingeniería de software y todo sistema que desarrollemos
debemos lograr que se desarrolle con calidad, cubriendo los estándares mínimos.
Proceso
Nuestro trabajo de desarrollo de sistemas va a estar organizado por un marco de trabajo, ese marco
es este proceso que nos va a ir definiendo una serie de actividades a desarrollar y que se aplica a todo
proyecto de software. Si yo desarrollo un proyecto de software tengo un proceso, este término proceso
está dentro de sistemas de información y es el proyecto de desarrollo, no confundir con la definición
de modelado de procesos de negocio, esta definición de este aparatado está en el contexto de un
desarrollo de sistemas.
Un proceso se va a definir como un marco de trabajo que va a determinar distintas actividades
aplicables a todos los proyectos de software independientemente de su tamaño y complejidad. El
fundamento de la ingeniería de software es el PROCESO.
Ese marco común de trabajo por
un lado define la serie de
actividades de ese marco de
trabajo, si yo desarrollo un
proyecto de software si o si
necesito definir qué actividades
voy a desarrollar, esas actividades
van a estar definidas, explotadas o
detalladas en un conjunto de
tareas. En esas tareas voy a ir
definiendo que tareas se tienen
que realizar, quien la va a realizar
y por otro lado los hitos y entregas
(si yo voy a entregar en 6 meses
por ejemplo cada 2 meses podría
establecer hitos para ir mostrándole al cliente cómo va el desarrollo del software).
El proceso va a definir quién (los recursos, que roles, analistas, programadores, etc.) está haciendo
qué (Acciones, actividades), cuando (porque le tenemos que dar un tiempo) y cómo logra cierta meta.
Forma la base para el control de la
gestión de los proyectos de software.
Análisis de Sistema Resumen Nicolás Aguirre
Métodos
Los métodos definen como vamos a construir técnicamente un sistema. En esta tarea es una
combinación de creación de modelos y actividades que tienen que ver con la gestión del proyecto. Hay
una planificación, estimación de proyectos y comunicación, el análisis de los requisitos o
requerimientos, el modelado del diseño, la construcción de programas, y por último la prueba y
mantenimiento.
Los métodos estarían identificando como construir un sistema abarcando lo anterior. Van estar
desarrollados según un conjunto de principios básicos. Siempre que modelemos algo vamos a estar
dentro de un paradigma y un conjunto de principios que establece ese paradigma para definir los
modelos conforme a esas reglas establecidas, esos principios gobiernan cada área de la tecnología e
incluyen actividades de modelado y otras técnicas descriptivas.
Cabe destacar que se llama técnica a un método estructurado y repetible para lograr una tarea
específica.
Herramientas
En este contexto de ingeniería de software herramientas esta utilizado como aquello que nos da un
soporte automatizado o semi automatizado para el proceso y los métodos.
Cuando yo integro esas herramientas para que esa información que yo cree con las herramientas
pueda ser utilizado estamos utilizando lo que se conoce como herramientas CASE (Ingeniería de
Software asistido por computadora), que combina hardware, software y bases de datos conteniendo
información importante sobre el análisis, diseño, construcción y prueba de sistemas. Las herramientas
son principalmente gráficas, se trabaja mucho con modelos.
Calidad y CMM
Hay un instituto que es el SEI (Instituto de Ingeniería de Software) que desarrollo un modelo completo
que establece una serie de funciones que debería hacerla ingeniería de software con una serie de
estándares y si un software desarrollado cubre ese nivel lo califica y permite certificar el nivel de calidad
de ese desarrollo de software. De ahí surge el CMM que es un modelo de capacidad de madurez
(Capability Maturity Model) establece una serie de niveles de forma tal que yo mida a un software
desarrollado y si cubre esos estándares, cumple con un nivel y estaría evaluado y calificado en el
mismo.
De esta forma si una organización tiene el desarrollo de un software y quiere que sea calificado,
justamente va a aplicar este análisis que será analizado por evaluadores y califican si tiene un nivel
obtenido de CMM o no.
Un modelo de madurez es una colección estructurada de elementos que definen ciertos aspectos de
la madurez de una organización, en otras palabras, es un método para definir y gestionar procesos a
realizar por una organización.
Este modelo de calidad establece un conjunto de prácticas o procesos claves, o más bien un conjunto
de buenas prácticas que está definida de esta forma: si el desarrollo del sistema fue desarrollado en
tales condiciones, cumplió los tiempos, satisface al cliente, define una serie de elementos o de buenas
prácticas o de cómo se desarrolló el mismo de manera que si este sistema desarrollado cumplió con
eso certifica un nivel de CMM y si no cumplió estaría con una evaluación negativa, indicando que se
Análisis de Sistema Resumen Nicolás Aguirre
desarrolló un software de baja calidad. CMM evalúa los procesos en sus distintos niveles de madurez
para cumplir con una cultura de excelencia en el desarrollo de software.

Cuatro P de la ingeniería de software

Análisis de Sistema Resumen Nicolás Aguirre

Personas
Siempre que desarrollemos un sistema vamos a tener personas involucradas. Cuando hablamos de
personas nos referimos a todos los que estén involucrados en el desarrollo de ese sistema. Por un
lado, todos los que tienen que ver con los autores del proyecto o los que lo van a desarrollar con los
distintos roles, pero todo profesional de sistema que participe de un proceso de sistemas estaría
integrado en este concepto de las personas que participan en este desarrollo. Arquitectos,
desarrolladores, ingenieros de prueba y el personal de gestión, usuarios, clientes y otros interesados
(stakeholders), etc.
Desde que la persona tiene un interés, el cliente o el dueño o un área de la organización tiene un
interés ahí es que aparecen las primeras personas intervinientes en el desarrollo de software. Se
contactará con el equipo de profesionales que desarrollaran el software para luego satisfacer las
necesidades de ese solicitante.
Las personas para todo desarrollo de software son todos los involucrados en el proyecto durante todo
su ciclo de vida pudiendo ser que participen financiando, testeando, creándolo, etc.
Proyecto
El proyecto está hablando de toda gestión de proyectos. Es como un elemento organizativo a través
del cual se va a gestionar el desarrollo propiamente de este sistema o de este software. Este elemento
organizativo le va a dar un tiempo, va a definir esa gestión de proyecto, establece recursos, el ciclo de
vida que se va a desarrollar para que ese software pueda tener un inicio hasta un fin, y también hace
la gestión de esa presupuestacion y el seguimiento y control de avance del mismo. Es un elemento
organizativo a través del cual se gestiona el desarrollo del software. El resultado de un proyecto es
una versión del producto.
Es un esfuerzo temporal, que se lleva a cabo para crear ese producto, servicio o resultado único. Lleva
toda esta organización a través de un ciclo de vida, una serie de pasos y la búsqueda es para lograr
un resultado final que es dar el resultado esperado a ese cliente.
Producto
El producto está orientado al resultado, son los artefactos que se crean durante toda la vida del
proyecto como los modelos, código fuente, ejecutables y documentación.
El producto es más allá de solo el sistema programado, sino que se refiere a algo integral, al código
fuente más toda la documentación que acompaña al desarrollo de ese sistema.
El resultado final es el producto del sistema, toda la programación del sistema más la documentación
con los modelos y todo el trabajo organizado son los artefactos o producto de un sistema informático.
Proceso
Es el conjunto completo de actividades necesarias para
trasformar los requisitos de usuario en un sistema de
software. También se lo conoce como proceso de desarrollo
de software. Ese sistema desarrollado atiende al producto
de lo que vamos a desarrollar. Es el mapa que se sigue.
Análisis de Sistema Resumen Nicolás Aguirre
Integración de las 4P
Cada vez que desarrollemos un sistema tendremos personas involucradas, que deben estar
organizadas bajo un proyecto porque este me dice, organiza y temporaliza que voy a hacer. Va a ir
acompañado y va a estar integrado por un proceso que va a decir las actividades en ese tiempo que
voy a cumplir bajo qué presupuesto y con qué reglas y definiciones que se establecieron y todo va a
ser en pos de producir un resultado, un conjunto de producto finales que comprende el sistema, el
software completamente más la documentación que acompaña.
El proceso de desarrollo de software
Este proceso de desarrollo establece un marco de trabajo, ese marco de trabajo es común al proceso.
Concretamente significa el conjunto de actividades que vamos a desarrollar como profesionales
aplicables a todos los procesos de software.
El proceso de desarrollo de software es el conjunto de todas las actividades necesarias para
transformar los requerimientos de ese cliente que son todas las características que el sistema es capaz
de hacer entiendo todos los servicios que debe ofrecer y considerando todas las restricciones que
deba considerar, en un software.
Marco de trabajo del proceso de software
Dentro de este marco de trabajo también está integrado dentro de una gestión de proyecto, que está
establecida como las actividades sombrillas o de protección. Nuestro marco de trabajo o proceso es
un conjunto de actividades, las actividades van a estar desglosadas como un conjunto de acciones
donde cada conjunto de acciones tiene quien va a hacer cada función, cuando son los hitos y demás.
Ese conjunto de tareas está referida a toda la colección de acciones necesarias para desarrollar un
proyecto que está dentro de la ingeniería de software
Las actividades sombrillas o de protección son todas las acciones que hacen a a la gestión de
proyectos. Todos los proyectos tienen que tener las tareas a realizar y una gestión, alguien que
coordine los recursos, los tiempos, el control de avance, el aseguramiento de calidad, el análisis de
riesgo que permita desarrollar el software completo.
Las tareas están enfocadas en la acción a realizar, el producto que tengo que obtener, la actividad
concreta y la función que tengo que hacer en los tiempos establecidos.
De esta forma combinando las tareas en la actividad sombrilla se desarrolla de forma completa un
sistema.
Actividades sombrilla o de protección
Estas actividades acompañan el desarrollo de todo el sistema, algunas estarán más desarrolladas más
fuertemente en el inicio, algunas son durante todo el proyecto, algunas tienen un trabajo o esfuerzo a
mitad del proyecto y algunas desde que comienza hasta que termina el proyecto tienen acción sobre
el proceso.
Principalmente están definiendo el seguimiento y control de proyectos de software, la preparación y
producción del producto de trabajo que significa que el proceso de desarrollo tiene requerimiento
codifica crea modelos y demás, entonces la gestión de proyectos se encarga de establecer en el cliente
las características técnicas, si tiene el software necesario de base, el entorno de producción. Por otro
lado, la gestión de reutilización de lo que se pueda reaprovechar, de lo que ya existe. También se
Análisis de Sistema Resumen Nicolás Aguirre
encarga de la gestión de configuración del software, por otro lado, la medición (momentos en que se
evalúa si los hitos se van cumpliendo), además de revisiones técnicas formales con el cliente, a la vez
hay una serie de evaluaciones que consisten en medir la calidad del software y por último se definen
los riesgos del proyecto, planes de contingencia, de liquidación en la gestión del riesgo.
Problemas del proceso de desarrollo
Las problemáticas que se presenta son por ejemplo como intervienen distintas personas en un
desarrollo de sistemas, cada una con distintos roles, a veces se presenta la dificultad al desarrollar
software que si las personas que intervienen no tienen en claro que actividades realizar va a haber
una problemática porque el equipo no está organizado para el desarrollo de sus actividades.
La segunda problemática es que, si yo no tengo claro el rol, y a la vez no tengo una forma organizada
de trabajar entonces no llego a buen término con el resultado esperado.
En función de eso surge como una necesidad de tener este conjunto de actividades organizado. Todos
los profesionales en sistemas necesitan tener un proceso de desarrollo definido
Propósito del proceso de desarrollo
Todos los profesionales de sistema necesitan un proceso que proporcione una guía para ordenar las
actividades de un equipo, que dirija las tareas de cada uno con su rol por un lado de forma individual
y por otro lado tenemos actividades que se corresponden en la integración del equipo. Tenemos que
definir cuáles son los productos que yo quiero tener, los artefactos o modelos que quiero hacer y bajo
que paradigma o concepción voy a modelar algo, codificar y crear el producto. Y por último que me
establezca elementos para el control de esos productos para que la gestión de proceso me permita
decir si voy bien y ajusta lo necesario para llegar a buen término.
Actividades genéricas de los procesos de desarrollo
Existen una serie de actividades genéricas en los procesos de desarrollo que no importa dentro de
que paradigma yo desarrolle el software, siempre que yo hago un sistema tengo que al menos
desarrollar estas actividades. Son aplicables a la mayoría de los proyectos de software, pero no a
todos porque algunos tienen un desarrollo particular por tanto para ese tipo de proyecto no incluye
estas actividades, sobre todo en sistemas expertos.
Las actividades son las siguientes.
Comunicación
Siempre que yo inicie un sistema va a haber una actividad genérica que me comunique con un cliente,
con una necesidad y, por otro lado, de mi lado, con un equipo profesional. A eso se refiere la actividad,
y yo con el cliente lo que voy a hacer es encontrar los requerimientos. Siempre hay una primera
actividad denominada comunicaciones que tiene que ver con la búsqueda, o la investigación de esas
necesidades del cliente y con el establecimiento de los requerimientos, algo que me diga qué es lo
que tengo que hacer y de esta forma puedo luego preparar la propuesta del sistema.
Abarca la investigación de requisitos y actividades relacionadas de elicitacion de requerimientos, en el
relevamiento de datos, búsqueda de información y detección de problemas. Realizar análisis de
requisitos o análisis de sistemas, estamos hablando de una de estas actividades genéricas. Tomar
conocimiento de la problemática de ese cliente, de ese usuario, ver su contexto, ver el entorno,
investigar, conocer cómo funciona, que datos maneja y proponer un sistema.
Análisis de Sistema Resumen Nicolás Aguirre
Planeación
Una vez que tengo detectado los requerimientos y qué quiero hacer lo que voy a definir acá, que tiene
que ver bastante con estas actividades sombrilla o estas actividades de gestión de proyecto tengo que
definir las tareas que se van a desarrollar, los riesgos que puedo llegar a tener, los recursos que serán
requeridos (personas, tecnologías, demás), los productos que han de producirse y un programa de
trabajo (mapa para que todos sepan que hay que hacer, en que tiempos, y demás).
Modelar
Siempre que yo vaya a desarrollar un sistema informático tengo una tarea que es la de modelado, la
creación de modelos que le permitan al profesional de sistema crear un modelo y el cliente ver la
propuesta de sistema y entender mejor los requisitos de software.
Entender los requisitos del software y realiza los modelos representando la solución del sistema que
logre satisfacer esos requerimientos y esas necesidades y problemáticas que tiene ese cliente.
De aquí tenemos dos actividades principales que incluyen este modelado. Por un lado, la acción
fundamental de hacer análisis y la acción fundamental de hacer diseño.
Análisis
Cuando hacemos análisis de sistemas vamos a estar definiendo el que debe estar haciendo el sistema,
es decir, el comportamiento y rendimiento que se desea que el sistema logre con las restricciones
existentes. Son todas las características que el sistema deberá considerar según los servicios a ofrecer
y las restricciones. Nuestro disparador para hacer esta tarea de análisis y encontrar el que debe hacer
el sistema son los requerimientos que parten desde que yo tomo la información que investigué, elaboro
la lista de requerimientos, voy a negociar con el cliente si es lo que yo propongo lo que él quiere, lo
especifico y lo valido.
El resultado de la tarea de análisis es crear un documento “especificación de requisitos”.
Diseño
Va a definir el cómo hará el sistema para que lo que yo propuse que debe hacer el sistema funcione,
le agrego toda la implementación, incluyendo diseño de la estructura de datos, diseño arquitectónico
y se crea modelos de diseño.
Construcción
Es la codificación o la generación de lo que es el código y programación de sistema según lo que está
estipulado en el análisis y en el diseño de lo que el sistema tiene que hacer y cómo debe hacerlo. Se
usa un lenguaje de programación definido, se construyen las bases de datos y demás.
Además, consiste en la realización de pruebas del sistema desarrollado para descubrir errores en el
código.
Despliegue
Comprende la entrega del software al cliente. EL producto completo puede entregarse de formas
parciales incrementales o completo. La idea es que se entregue de forma parcial a través de
iteraciones o versiones.
Análisis de Sistema Resumen Nicolás Aguirre
Eso significa como la puesta en producción, que significa que un sistema se pone en marcha, que se
va haciendo con las entregas parciales y el cliente va evaluando para ir viendo las devoluciones que
hace para lograr un producto final que logre cubrir los requerimientos y necesidades de ese cliente.
Flujos de proceso
Dentro de los procesos de desarrollo y teniendo en cuenta las actividades genéricas se han creado
distintos modelos de proceso considerando como que forma organiza estas cinco actividades y en qué
línea y en función de eso surgieron distintos flujos de procesos que dieron pie a la creación de distintos
modelos de procesos.
Describen las maneras en que están organizadas las actividades estructurales y las acciones y tareas
que ocurren dentro de cada una con respecto de la secuencia y el tiempo.
De esta forma estas cinco actividades podrían estar en un proceso lineal (una tras otra), iterativo (voy
avanzando y vuelvo según el tipo de avance que tenga) o un proceso evolutivo (va creciendo con
incrementos) o paralelos (desarrollo en las del inicio y después en las siguientes según el avance del
tiempo).
Modelos de proceso de software
Estos procesos de desarrollo los podemos agrupar en dos grandes grupos. Por un lado, están los
modelos prescriptivos de proceso y por otro lado toda esa nueva corriente que surgió de las
desventajas, inconvenientes que estos modelos prescriptivos proponían y se desarrolló una nueva
forma de dinámica de trabajo, de organizar el equipo, dando como la creación, la apertura a nuevas
búsquedas, nuevas formas de organizarse y surgieron las metodologías ágiles.
Modelos de proceso prescriptivos
Estos modelos de procesos prescriptivos dentro de esas actividades genéricas una forma de en qué
secuencia llevarlos, en que tiempo desarrollarlos. Primero surgió uno muy tradicional y luego surgieron
variantes queriendo mejorar el proceso y los resultados.
Definen un conjunto distinto de actividades, acciones, tareas, fundamentos y productos de trabajo que
se requieren para desarrollar software de alta calidad.
Determinan en el marco de trabajo un conjunto de tareas explicitas, siendo el objetivo de este modelo
de proceso mejorar la calidad del sistema, lograr proyectos más manejables pero la dificultad que vino
es que a medida que se hacían más complejos los diseños de sistemas la gestión de ese proyecto se
vuelve inmanejable, lo que puede llevar al fracaso del mismo. Estos modelos prescriptivos querían que
sean más manejables los proyectos de mayor dimensión. Por otro lado, hacer mas predecible las
fechas de entrega y los costos.
También se había llamado ciclos de vida, también se llamaron metodologías, pero nunca se pueden
aplicar así nomas, sino que deben adaptarse a las condiciones de mi equipo, un problema en particular
para que ese modelo de procesos me sirva para que yo desarrolle en forma concreta un sistema.
Metodologías Ágiles
Ponen como un énfasis en la agilidad del proyecto, en lograr un resultado más pronto que con los
métodos tradicionales prescriptivos. La agilidad busca lograr un avance más rápido en cuanto
resultados a ser mostrados al cliente. Siguen un conjunto de principios que conducen a un enfoque
más informal, sin tanta burocracia, teniendo procesos puros agiles y mas híbridos, pero la idea
Análisis de Sistema Resumen Nicolás Aguirre
conceptual de la agilidad es buscar reducir un poco la documentación, y conseguir resultados más
rápidos.
Se dice que son agiles porque acentúan la maniobrabilidad y la adaptabilidad. Tienen que ver con ir
adaptando el sistema y manejando esos cambios de requerimientos por parte del cliente. Son útiles
cuando se hace ingeniería sobre aplicaciones web, o Mobile.

Tipos de modelos descriptivos

Modelo en cascada

Es el primero que surgió, es de tipo lineal y tiene un enfoque sistemático y secuencial. Tiene una
utilidad para requerimientos que son fijos. ¿Cómo es una cascada? Cuando va bajando el agua no
vuelve hacia atrás, de allí el concepto de este modelo. Yo hago una primera actividad, de las genéricas,
y el concepto de cascada secuencial lineal es que paso a la siguiente una vez que termino el anterior
y ya no vuelvo.
Análisis de Sistema Resumen Nicolás Aguirre
También se lo denomina lineal secuencial o ciclo de vida clásico
Inicialmente cuando nosotros empezamos a desarrollar sistemas fue el ciclo de vida clásico el que
todos los profesionales tomaban, y las principales dificultades son que desde el inicio del proyecto el
cliente debería tener claro sus requerimientos y la realidad es que los sistemas se construyen en una
forma de que van evolucionando los requerimientos, si bien el cliente sabe que es lo quiere, a medida
que avanza el tiempo se va ajustando los requerimientos que solicita para satisfacer sus necesidades.
Tiene estados de bloqueo, lo que significa que yo no paso a la siguiente actividad hasta que no termino
la anterior, esto es un problema porque cuando se establecía los requerimientos del cliente y cuando
entregábamos el producto al cliente el producto terminado, como él anteriormente no había
interactuado con la propuesta de software, de repente veía el producto terminado pero cuando lo
empezaba a probar no era lo que él quería, entonces teníamos que volver al inicio repensando de
nuevo todo el proyecto. Este modelo no tiene iteración en la secuencia de acciones genéricas.
Modelo en V
Tiene una primera línea trabajando igual con las actividades
genéricas en una secuencia de cascada, pero con una
modificación en esa secuencia estableciendo distintas
pruebas durante la ejecución o desarrollo de ese sistema.
Se va incorporando una serie de validaciones durante el
desarrollo del sistema para amortiguar que no llegue al final y
el cliente recién lo vea ahí y venga una serie de
modificaciones condicionantes o insatisfacción del cliente
porque no le sirve.
Justamente amortigua las desventajas del modelo en
cascada.

Modelo incremental
La forma en que este modelo funciona
justamente tiene las cinco actividades
genéricas que tenemos, pero en su
propuesta va a ir desarrollando como
versiones que van a ser: el primer
incremento va a tener como los
principales requisitos que tiene ese
cliente y que le voy a poder entregar.
Combina algo incremental y algo de vida
clásico es porque yo voy a tomar un
incremento que va a ser un conjunto de
requerimientos, ese conjunto va a ser
desarrollado vía un ciclo de vida clásico,
pero yo le voy dando por partes, por
incrementos al cliente, entones el cliente
Análisis de Sistema Resumen Nicolás Aguirre
en esta primera entrega ve esto que se llama el producto fundamental, el concepto con las principales
funciones del sistema. En un siguiente incremento voy avanzando con nuevas funcionalidades y voy
modificando lo que el cliente vio y me hizo una devolución en el primer incremento. De esta forma se
va construyendo incremento a incremento el sistema hasta llegar a un último conjunto de secuencia
de acciones que realizo que completa el producto total.
Las características resumidas son:

Modelo de procesos evolutivos

El sistema se desarrolla en iteraciones hasta llegar a una versión final. Estos modelos de procesos
evolutivos permiten ir incorporando en el desarrollo del mismo, requerimientos de negocios y
modificaciones en lo que está queriendo obtener ese cliente. Este conjunto de modelo de procesos
evolutivos presenta tres modelos en sí mismo
Modelo de construcción de prototipos
El concepto de prototipo surge cuando nosotros
desarrollamos sistemas y queremos ver que necesita ese
cliente y validarlo con él, de ahí surge el prototipo.
Tenemos que armar un modelo de prueba a escala de lo
real para validar o analizar algo, concretamente el diseño
de pantalla y ventanas serán los prototipos de nuestra
profesión.
La primera iteración o vuelta va a identificar las
principales necesidades o ese requerimiento global de lo
que quiere y vamos a pasar por la serie de distintas
acciones, empiezo a modelar el prototipo, lo valido con el
cliente, se lo muestro y en función de la devolución ajusto
lo necesario. De esta forma voy evolucionando, construyendo el prototipo y creciendo por cada
Análisis de Sistema Resumen Nicolás Aguirre
iteración en el desarrollo del sistema. Esto busca de las desventajas del ciclo en cascada ir a que el
cliente vea rápidamente lo que quiere, nosotros les mostramos que se puede hacer y vamos
construyendo en conjunto por cada iteración el sistema.
El uso de prototipos se usa en distintos modelos porque es lo que el cliente entiende, comprende y me
sirve a mí para ajustar requerimientos y entender que es lo que quiere. Permite identificar y mejorar la
compresión cuando los requerimientos no están claros.
Modelo en espiral
Combina el ciclo cascada con el modelo
incremental y la construcción de prototipo.
Empieza desde el centro y vamos a ir pasando por
las cinco actividades genéricas y con cada vuelta
haremos una iteración y eso es un incremento y
mientras diseñaremos prototipos a la vez que se
contacta con el cliente para irle mostrando.
Cada nueva versión en este espiral va creando
una versión cada vez más completa del sistema
hasta que alguna vez vamos a completar todo.
El primer circuito alrededor de la espiral da como
resultado el desarrollo de una especificación del
producto, en vueltas sucesivas tal vez voy tenido la construcción de prototipos, lo valido con el cliente
y en versiones más avanzadas logro el resultado del software.
Logra un desarrollo más rápido de versiones que cada vez están más completas.
Modelo de desarrollo concurrente
Es un diagrama que por cada
actividad voy a ir llevando una
secuencia de control del estado,
como va desarrollándose la misma.
Representa el estado de una
actividad de la ingeniería de
software. Para un proyecto
particular y para un conjunto de
funciones, vamos a tener un
modelo para cada actividad.
No es tan utilizable porque no hay
un seguimiento de esa forma, no
hay un uso específico en el
seguimiento de cada uno de estos
estados.

Representa una serie de actividades del marco de trabajo, acciones y tareas y sus estos asociados.
Análisis de Sistema Resumen Nicolás Aguirre
Sirve en situaciones donde si yo tengo un proyecto que es de mayor envergadura y lo voy a dividir por
distintos tipos de proyecto donde cada uno maneja una parte sirve para dar visibilidad de cuál es el
estado que esta cada una de las actividades de la ingeniería de software para cada uno de los equipos.
Esta bueno el poder saber cuándo uno va a desarrollar el sistema el estado de avance que tiene cada
función.
Modelos especializados de procesos

Metodologías Ágiles
Estos procesos agiles estarían como una nueva corriente que se separó un poquito de los modelos
prescriptivos. También surgió a partir de los inconvenientes de los modelos clásicos y se propuso una
nueva dinámica, una nueva forma de trabajar. Entonces se estableció esta metodología ágil con
algunas características generales y luego unas particulares que tienen mucho uso.
Este tipo de actividad y de desarrollo de sistema sirve mucho para desarrollar sistemas donde los
requerimientos de los clientes no están tan claros desde el inicio y pueden ir cambiando y se adapta
mucho el desarrollo del sistema con el avance del desarrollo con esta cuestión de interacción, mucha
interacción con el cliente, se disminuye la cantidad de documentación, va más al resultado y a poder
validarlo conforme se avanza para darle un resultado al cliente de calidad.
Esta nueva tendencia propone una forma de trabajo orientada más al resultado, pero todas partieron
de un sistema clásico, marcando tendencias diferentes. Sirve mucho para el cambio de requerimiento
debido a que se adapta muy bien. En los otros sistemas pueden ir creciendo los requerimientos, pero
si estos cambian hay un mayor costo y muchas más desventajas y consecuencias de esos cambios
de requerimientos, la metodología ágil amortigua más esos cambios de requerimientos.
Análisis de Sistema Resumen Nicolás Aguirre
En vez de hacer una planificación macro, va haciendo planificaciones parciales y que se pueden ir
adaptando conforme se avanza. Vamos a desarrollar el sistema con todas las acciones genéricas pero
diferente el tiempo insumido en las acciones, se acota más y se desarrolla en paralelo, principalmente
en análisis y diseño.
Se basa en un conjunto de métodos o un grupo de métodos que desarrolla un sistema de forma
iterativa e incremental. De esa forma van a ir especificando, diseñando e implementando el software
(programar en código). Trabaja mucho en forma colaborativa y los equipos son multifuncionales y
están auto organizados.

La más usada en el mercado es SCRUM.

Análisis de Sistema Resumen Nicolás Aguirre
El proceso unificado de desarrollo de Software (PUD)
Lo podemos definir como el conjunto completo de actividades, métodos fundamentos y practicas
necesarias para transformar los requisitos de un usuario en un conjunto consistente de artefactos
(producto) que conforma un producto de software.
También lo podemos llamar como un entorno de procesos genérico, framework o marco de trabajo
genérico. La idea que propone ese conjunto de actividades para desarrollar un sistema completo
puede utilizarse para una gran variedad de sistemas de software, diferentes áreas de aplicación,
diferentes tipos de organizaciones, niveles de aptitud y tamaño de los proyectos.
Para completar el proceso unificado utiliza lo que es el lenguaje unificado de modelado, siendo el
proceso unificado como un conjunto de actividades genéricas y por otro lado lograron construir un
lenguaje unificado de modelado que es el UML en donde a todos los diagramas se les definió
simbología, notación estandarizada para ese modelo.
Este modelo se basa en el paradigma orientado a objetos y se utiliza para preparar todos los
esquemas, modelos de un software.
El proceso unificado de desarrollo es un proceso de desarrollo y UML es un lenguaje para modelar, se
complementan, pero no son lo mismo. El PUD es un ciclo de vida que establece el conjunto de
habilidades para realizar un sistema informático y crear los distintos modelos y en esa creación vamos
a utilizar una notación que es UML para la representación y graficacion que sustentan las propuestas
de sistemas
Características esenciales del PUD
Dirigido por casos de uso
Propone un concepto para representar funciones (casos de uso) un caso de uso va a ser un fragmento
de funcionalidad que el sistema va a considerar y que le va a otorgar o proporcionar al usuario un
resultado importante para cubrir una función.
Van a considerar los requerimientos funcionales y de esos los vamos a modelar y representar,
especificar y seguir avanzando a través de casos de uso.
Dirigido por casos de uso significa que yo voy a encontrar requerimiento y una vez que los tenga, a los
funcionales les identificare casos de uso (fragmentos de funcionalidad que atiendan un requerimiento
funcional) y el desarrollo del todo el sistema pasando por todas las actividades del mismo va a seguir
un hilo conductor, ese caso de uso lo definí, luego lo especifico, doy la lógica , establezco los modelos,
codifico, hago la prueba y todo el sistema se construye a partir de los casos de uso que son las
funciones del sistema.
Los casos de uso guían el proceso de desarrollo del software.
Centrado en la arquitectura
Cuando construyamos un sistema construiremos distintas vistas del mismo que mostraran aspectos
dinámicos y estáticos que son significativos del sistema. Todas esas vistas constituyen la arquitectura
de software.
Nosotros vamos a construir un mapa para los dispositivos de hardware que conforman el sistema, otra
vista que va a mostrar los componentes de software que muestran como se relacionan y considerar
estos aspectos dinámicos y estáticos que son la arquitectura de software. Usaremos UML y el PUD
Análisis de Sistema Resumen Nicolás Aguirre
para esto. El conjunto de todas estas vistas me dará la construcción completa y todo ese soporte
necesario de ese sistema.
Los casos de uso y la arquitectura se complementan: los casos de uso me van a dar la función de ese
sistema y la arquitectura y vistas me darán la forma de ese sistema.
Iterativo e incremental
Para construir este desarrollo de sistema lo que propone es dividir el desarrollo en iteraciones que
ejecuta una serie de pasos y el resultado de cada iteración va haciendo un incremento que permite
ese crecimiento del producto, del desarrollo de sistemas, del software. Cada iteración debe estar
planificada y debe tener un control de avance para garantizar que vamos a cumplir con la mayor
efectividad lo establecido para esa organización.
Por cada iteración se realizan todas las actividades genéricas, denominadas como análisis de
requisitos, análisis propiamente dicho, diseño, implementación y prueba del sistema.
La vida del proceso unificado
El proceso unificado propone cuatro grandes frases que son inicio, elaboración, construcción y
transición.
Este proceso unificado se repite a lo largo de una serie de ciclos que va a ser una iteración, que están
planteadas por columnas y las fases van a ir logrando dentro de este desarrollo pasar por una iteración,
hacer una versión del producto y va a ir creciendo por cada versión.
En este desarrollo completo va a ir aplicando la identificación de casos de uso, va a ir creando las
vistas de arquitectura y desarrollando todos los modelos, la codificación, programación y prueba del
sistema.
Fases y flujos de trabajo de un ciclo
En una primera columna acá se llama flujo
de trabajo, propone cinco flujos de trabajo:
flujo de trabajo requisitos, flujo de trabajo
de análisis, flujo de trabajo de diseño, flujo
de implementación, fuljo de trabajo prueba.
El flujo de trabajo lo que establece es que
actividades hay que hacer dentro de ese
flujo y que artefactos lograra producir. Lo
otro son las fases y la idea del grafico es
mostrar el esfuerzo de cada flujo de trabajo
en cada fase.
Inicio: está orientado a un trabajo de
planificación, defino un listado de
requerimientos.
Elaboración: orientado a la creación de modelos y estructura lógica.
Construcción: orientado a la programación en sí.
Transición: orientada al despliegue, a la puesta en marcha o producción del sistema.
Análisis de Sistema Resumen Nicolás Aguirre
Conceptos básicos del proceso

Análisis de factibilidad de un proyecto

Un estudio de prefactibilidad es como un análisis del sistema que yo estoy proponiendo antes de
empezar a ahondar en el detalle y ponerme de lleno a trabajar tengo que hacer un análisis de si esa
propuesta es factible de llegar a buen puerto. Yo no puedo hacer propuestas que estén en el aire o
inalcanzables porque no se puedan lograr o propuestas fuera del presupuesto. Tengo que hacer
propuestas de un sistema dentro de todo lo que se me ocurra hacer que sea acorde a algo que se
puede concretar. Eso significa hacer el estudio de prefactibilidad. Es el análisis de si resulta viable o
no el desarrollo de un sistema informático que se propone realizar. Se le llama prefactibilidad porque
es más general y se hace al inicio de un proyecto.
Si yo propongo algo, al menos tengo que pensar si eso se puede llegar a ejecutar, tengo que analizar
unas variables para que me garantice que eso va a llegar a un término real y concreto.
La factibilidad significa establecer si el proyecto propuesto ayuda a que la organización logre sus
objetivos generales, encontrar cuales son los objetivos organizacionales y ver si el proyecto sirve para
colaborar y favorecer el negocio hacia sus objetivos e alguna forma o si su desarrollo resulta útil a la
sociedad y resuelve las necesidades del contexto al cual está dirigido.
Actividades de un análisis de factibilidad
Entender el proyecto
Establecer la duración y tamaño del proyecto
Determinar costos y beneficios
Determinar la fiabilidad del sistema
Elaborar un documento con recomendaciones en el cual debe quedar si el proyecto es o no factible
Análisis de Sistema Resumen Nicolás Aguirre
Para qué sirve el estudio de prefactibilidad
Para evitar desarrollar proyectos que no son factibles, no me voy a embarcar en un proyecto que
después voy a ver a la mitad que no se puede implementar, me va a permitir planear recursos en
función de la complejidad y tamaño de ese proyecto y la duración, las personas a trabajar, las horas a
trabajar y todo lo que me haga falta para el desarrollo del mismo. Y por último determinar expectativas
reales del sistema de los futuros usuarios para ver si esas expectativas del cliente son realizables o
no.
Análisis técnico
Esta hablando de toda la cuestión de tecnología y equipamiento asociada a la propuesta y que ese
desarrollo de un sistema va a necesitar. Yo voy a analizar si la propuesta que estoy haciendo necesita
como soporte un equipamiento, una tecnóloga. Debo analizar si tengo disponible esa tecnología, si es
accesible, está en el mercado, o si esa organización la tiene para que este sistema pueda funcionar
bajo ese soporte técnico. Debe considerarse en general el equipamiento y la tecnología de base
necesaria para el soporte de sistema de desarrollo.
Esta tecnología que estamos hablando son cantidad de equipamientos, impresoras, características de
cada uno de esos equipos, todo el sistema de soporte en la parte de software necesario para el
desarrollo, todos los accesorios técnicos necesarios.
Este análisis busca determinar si los recursos técnicos actuales pueden ser mejorados o añadidos
para satisfacer la petición bajo consideración.

Análisis económico
Lo que busca es una relación costo beneficio. Siempre que desarrollamos un sistema sabemos que
hay costos involucrados y por otro lado vamos a obtener beneficios luego de su implementación, la
idea es lograr este análisis. El cliente lo que más analiza son los costos, y está esperando los
beneficios, pero los va a tener a posteriori de la implementación del sistema, pero los costos los tiene
desde un inicio. Hay que valorar esta relación costo beneficio y lograr justificarle al cliente que la
propuesta le va a ofrecer una serie de beneficios que van a justificar el costo del desarrollo del sistema.
La idea es mostrar los beneficios y cuáles serán los costos par a desarrollar este sistema.
Análisis de Sistema Resumen Nicolás Aguirre

Análisis operativo
Tiene que ver con todos los recursos
humanos que van a estar afectados al
uso y relación con el sistema. Cuando
yo tenga que analizar la parte operativa
mucho depende cual es el usuario que
le dará uso al sistema para ver el diseño
de las interfaces, que sean intuitivas, la
capacitación que deba hacer, si cuento
con un usuario que conoce o no de
sistema, manuales de usuario que
guíen más, etc.
El análisis operativo es analizar todos
estos aspectos referentes de los futuros
usuarios del sistema que son los recursos humanos que estarán afectados al sistema. Esto es debido
a que define como van a hacer uso del sistema y como deberé diseñar las ventanas.
Análisis de Sistema Resumen Nicolás Aguirre
Resultado del análisis de prefactibilidad
Yo voy a hacer un análisis de prefactibilidad para saber si la propuesta de un sistema es viable o no
de que se pueda realizar, si es viable continua con el proyecto y si no es viable tendré que replantear
algo.
UNIDAD 3: PARADIGMAS ORIENTADOS A OBJETOS
Paradigma
Establecen una serie de principios que determinan el comportamiento de un grupo, comunidad u
organización. De allí que se caracteriza por tener ese grupo de seguidores bajo ciertas formas de
comportamiento semejante y de a partir de allí con una serie de normas, de reglas que determinan lo
que sea. De esta forma establece patrones de comportamiento que son comunes en ese grupo y va a
estar formados por ideas, creencias, emociones, actitudes que a lo largo de nuestra actividad vamos
incorporando en estos esquemas mentales dentro de esa estructuración en la cual estamos insertos
El paradigma lo podríamos también completar como que es la forma en que nosotros podemos percibir
algo o ver algo, en el sentido de la interpretación o entendimiento de esto, de alguna forma busca la
estructuración del pensamiento y de ver las cosas.
Tomas Khun dijo del paradigma: “Es un conjunto de teorías, estándares y métodos que juntos
representan una forma de organizar el conocimiento, es decir, una forma de ver el mundo”.
Paradigmas y sistemas
El paradigma va a ser una filosofía que considera un conjunto de métodos, herramientas y
procedimientos que le van a permitir al profesional de sistemas crear modelos y desarrollar sistemas
de información de forma clara, confiable, generalizada y dentro de esas reglas establecidas. Va a
trabajar con un filtro que va a poner límites indicando para resolver este problema dentro de estos
límites que establece el paradigma tendremos una serie de elementos para crear esos modelos y esos
modelos van a responder a esa filosofía dentro de ese marco teórico de referencia.
El paradigma nos va a ofrecer un modelo debido a que cuando creamos el sistema de información
tenemos que crear un modelo porque me permite comprender y simplificar esa realidad, ahora ese
modelo se crea bajo una serie de normas y definiciones, eso es el paradigma. De alguna forma
crearemos el modelo percibiendo ese mundo real y adaptándonos a una estructura dentro del límite,
de una filosofía predeterminada.
Surgimiento de nuevos paradigmas
Análisis de Sistema Resumen Nicolás Aguirre
Existe un paradigma vigente que se usa para resolver problemas pero lleva un momento donde este
paradigma no me ofrece todos los elementos para poder resolver situaciones, entonces hay una crisis
en cuanto a que ese paradigma no me sirve, no tengo la respuesta, entonces hay una búsqueda de
otra forma de resolver, de otro conjunto de herramientas, técnicas procedimientos y métodos y de allí
viene una revolución científica porque todo va con el conocimiento y establecimiento de algo nuevo y
de allí surge un nuevo paradigma.
Cada vez que tenemos un paradigma, o el surgimiento de uno nuevo va a establecer un marco de
teorías, creencias, valores, leyes, técnicas e hipótesis que establece ese marco teórica que explica
cómo se modela, interpreta o analiza a ambos y de esa forma vamos a poder comprender la realidad
y crear un sistema de información dentro de estos lineamientos, de lo que establece ese paradigma y
de alguna forma ir relacionando como el equipo de sistema desarrolla algo y sirve para la toma de
decisiones.
Surgimiento del paradigma orientado a objetos
La crisis del software
Dentro de lo que es el desarrollo del sistema hubo un momento donde se venía desarrollando de una
forma antes del paradigma orientado a objetos y esa forma empezó a hacer una serie de crisis en
donde el cliente no lograba satisfacción por los productos esperados o los profesionales no lograban
cumplir con el objetivo esperado o el desarrollo que necesitaban ofrecer a este cliente. En esta crisis
había una serie de errores cometidos por las personas encargas del desarrollo del software, errores,
pero no porque trabajaran mal, sino porque toda la tecnología y toda la situación se debían resolver
con otros elementos que actualmente no estaban en los actuales que se utilizaban para desarrollar
software.
De ahí que hubo como una serie de problemas que dispararon esta crisis del paradigma actual desde
el desarrollo del software que no preveía la evolución del hardware, el software no estaba ajustado a
esa evolución. También había planificaciones imprecisas debido a que se consumía más tiempo del
previsto. Esto conllevaba a que no se tuvieran los resultados deseados y se podía haber llegado a
usar otro software, pero hubiese implicado un mayor costo y no se tenía tanta flexibilidad, por ende, el
cliente estaba insatisfecho
Otro problema es que el software era poco confiable, de baja calidad y además era poco reutilizable.
El mantenimiento de estos softwares bajo este paradigma eran difícil mantener y se creaban sin
interacción con el cliente, solo se les mostraba el trabajo final, por ende, muchas veces este no
sobrevivía a la devolución del cliente.
La complejidad del software
Dada la crisis el software necesitaba un tratamiento de la complejidad y esa complejidad innata que
lleva el software se deriva en la complejidad del dominio del problema (situación de ese negocio que
tenemos que analizar), la dificultad de gestionar el proceso de desarrollo (modelo de procesos), la
flexibilidad que se puede alcanzar a través del software (el software no era flexible para hacer cambios)
y los problemas de caracterizar el comportamiento de sistemas discreto (la cantidad de elementos de
un sistema, las interacciones que requiere y la variabilidad de relaciones posibles, esto quiere decir
que a mayor complejidad en un dominio de un sistema en un software a desarrollar la forma actual de
ir modelando y creando la solución de un software empezó a hacer crisis, no lograba cubrir el desarrollo
de sistemas que resultaran óptimos).
Análisis de Sistema Resumen Nicolás Aguirre
Esa complejidad empezó a necesitar que se la pueda manejar de una forma. La forma de hacerlo es
descomponerlo en partes cada vez más pequeñas y trabajarlas en formas independiente, que siempre
serán menos compleja que la totalidad.
De allí que había en su momento una forma de descomponerlo y luego surgió la de orientada a objetos.
Primero existió la descomposición funcional y de ahí el paradigma estructurado que ahí tenía una
forma de ver y analizar el problema y de modelarlo. Eso fue bastante útil durante un tiempo, pero no
pudo cumplir el incremento de la velocidad y el avance del hardware, por ende, surgió una nueva forma
que es descomponer esa complejidad, encontrar objetos y construir un sistema con la descomposición
orientada a objetos.
Formas de descomposición
El paradigma estructurado trabajo esta descomposición funcional también denominada
descomposición algorítmica, de forma que la única manera donde podía dominar esa complejidad era
dividiendo el sistema en elementos funcionales, trabajo mucho sobre las funciones y ellas estaban
relacionadas entre sí estructuralmente, pero su foco fue enfatizar las funciones de un sistema y de esa
forma descomponer el problema y trabajar a través de esas funciones.
Enfatiza el orden de los eventos que me disparan las distintas funciones y va separando ese
tratamiento de funciones de los datos que maneja el sistema. Esos datos y funciones son visibles y
accesibles por todo el sistema.
La otra forma aparte de la descomposición algorítmica es la descomposición orientada a objetos que
introdujo una nueva forma con esta palabra objeto, establece un conjunto de agentes autónomos y
que los objetos colaboran entre sí para llevar a cabo un comportamiento. Esos agentes causan
acciones o son sujetos de estas acciones.
Los datos y comportamientos del sistema orientado a objeto se modelan juntos, por un lado, en la
algorítmica estaban muy separadas las funciones de datos, pero en la orientada a objetos el
comportamiento y los datos están encapsulados

Me propone que puedo modelar un sistema y construirlo visto como una colección de objetos. Nuestro
esfuerzo va a ser, después de analizar el negocio y el dominio del problema entender todo lo que
podemos resolver de ese sistema como objetos. La orientación a objetos propone un método de
descomposición que está basado en la integración de lo que es el sistema (conjunto de objetos) y lo
que hace el sistema (respuesta de los objetos a los mensajes que recibe). Entonces el sistema va a
ser un conjunto de objetos que colaboran entre sí para lograr algo que solos no podrían.
Análisis de Sistema Resumen Nicolás Aguirre
Características del paradigma orientado a objetos
Por un lado, ha permitido organizar el sistema de acuerdo con abstracciones de más alto nivel,
nosotros vamos a tener que entender algo y representarlo en ese dominio de problema como el
sistema. Concretamente el pensar en objetos es una forma más natural que las personas pueden
entender para un sistema.
Los sistemas suelen construirse a partir de objetos ya existentes.
La complejidad de los objetos que podemos utilizar sigue en aumento. Esto significa que la orientación
a objetos me permite continuar manejando la complejidad de esta identificación de estos objetos.
Los datos globales desaparecen, junto con las funciones que son parte interna de los objetos por lo
que los cambios solo afectan al objeto.
Análisis de Sistema Resumen Nicolás Aguirre
Fundamentos y elementos de la orientación a objetos
Objetos
La palabra objeto si vamos a la expresión del termino en sí, viene del latín de objectus, donde ob
significa “hacia” y jacere es “arrojar”.
Objeto seria cualquier cosa que se puede arrojar. Nosotros lo veremos desde el punto de vista de
sistemas, por ende, los objetos se consideran como conceptos de algo que se puede modelar que
pueden ser abstractos o concretos. Cualquier cosa que incorpore una estructura de un comportamiento
o acción que me puede servir para el sistema yo lo puedo considerar como objeto. Dentro de nuestra
percepción humana un objeto puede ser una cosa tangible y no visible. Pero no son las únicas, también
puede ser algo que puede comprenderse intelectualmente, por ejemplo, la venta es una acción, pero
esa venta podría comprenderla intelectualmente porque contiene comportamiento y datos que me sirve
para un sistema. Es algo hacia lo que se dirige un pensamiento o acción. A partir de allí puedo entender
objetos siempre que el objeto modele alguna parte de la realidad.
Tenemos una definición formal, que es la que vamos utilizar: “Un objeto representa un elemento,
unidad o entidad individual e identificable. Un objeto es siempre algo único, ya sea real o abstracto,
tangible o intangible. Tiene un papel bien definido en el dominio del problema, si yo identifico ese objeto
es porque messirve para modelar algo en la situación del dominio del problema, en el contexto que
estoy modelando”.
La naturaleza de los objetos
Todo objeto para ser identificado y que responda a nuestra interpretación tiene una naturalice, que es
decir que un objeto tiene un estado, comportamiento e identidad. Un objeto tiene un estado, exhibe
algún comportamiento bien definido y tiene una identidad única.
Un objeto tiene ESTADO
El estado de un objeto va a estar comprendiendo por todas las propiedades del mismo, más los valores
actuales de cada una de esas propiedades. Si yo tengo un objeto y digo que tiene una serie de
propiedades, las propiedades en si van a ser lo que llamamos atributos y a la vez cada uno de esos
atributos tienen algún valor.

El estado está representado por los

valores de los atributos. Un atributo
toma un valor en un dominio
concreto, pudiendo ser este valor
una mera cantidad o denotar otro
objeto.
Análisis de Sistema Resumen Nicolás Aguirre
Un objeto tiene un comportamiento
El comportamiento es como actúa y reacciona el objeto, en términos de su cambio de estado y el paso
de mensaje entre objetos.
Todo objeto no es solamente su definición de propiedades, es además su comportamiento que es
como va a actuar y reaccionar ante sus cambios de estado y como colabora y se comunica con otros
objetos. Este comportamiento va a representar su actividad visible y comprobable exteriormente, este
comportamiento es una operación que va a denotar un servicio que ofrecen todos los objetos del
mismo tipo.
Tenemos una integración de lo que es estado y comportamiento, donde se establece el termino de
responsabilidad, siendo esta aquella que incluye el conocimiento que un objeto mantiene (estado) y
las acciones que puede llevar a cabo (comportamiento).

Los tres tipos más comunes de comportamientos son los siguientes:

Análisis de Sistema Resumen Nicolás Aguirre
Un objeto tiene IDENTIDAD
La identidad se refiere a la propiedad que tienen los objetos en donde un objeto se lo distingue de
todos los demás objetos. Cada objeto tiene identidad única, incluso si su estado es idéntico al objeto.

Concepto de clases
Nosotros vamos a encontrar muchos objetos y vamos a ver de esos objetos justamente que hay un
conjunto que tiene una estructura común y un comportamiento común. Cuando un conjunto de objetos
comparte la estructura o comportamiento común estamos en posibilidad de identificarlo dentro de una
clase.
Si yo tuviera 4 caballos y un perro y lo que estoy queriendo agrupar son los que tienen estructura y
comportamiento común, esos cuatro caballos podrían conformar una clase y ese perro conforma otra.
Cada caballo es un objeto, el conjunto de esos objetos con estructura y comportamiento común es una
clase. Un solo objeto se lo llama una instancia de una clase.
Estas clases pueden incluir abstracciones que formen parte del dominio del problema, así como clases
que constituyan una implementación. Se pueden utilizar clases para representar cosas que sean
software, hardware o puramente conceptuales.
Naturaleza de una clase
Una clase podría representar dentro de una situación real los roles desempeñados por personas, los
lugares, las cosas, los roles desempeñados por organizaciones, conceptos, eventos/transacciones.
Toda clase va a tener dos vistas, una externa y otra interna.
La vista externa es la declaración de todas las operaciones (comportamientos) aplicables a todas las
instancias de la clase. Esta vista externa es lo que se denomina como interfaz
La vista interna engloba los secretos de su comportamiento. Se compone principalmente de la
implementación de las operaciones definidas en su interfaz. Es la parte de implementación.
Análisis de Sistema Resumen Nicolás Aguirre
Elementos del modelo orientado a objetos
Estos elementos están agrupados en esenciales y secundarios. Cuando yo cree un modelo, para que
este dentro de la orientación a objetos debe cumplir con las características esenciales. Además, hay
elementos secundarios que algunos objetos pueden tenerlo y otros no porque complementan su
identificación.
Esenciales
Abstracción
Es como una operación mental, la habilidad que tiene nuestra cabeza, pensamiento humano, para
poder identificar algo de ese mundo real, captarlo y definirlo bajo un modelo o cierto contexto. Esa
abstracción también va a depender de la vista de lo que quiero analizar y que parte me está sirviendo.
Yo voy a poder hacer una abstracción de algo del mundo real, siempre y cuando sea algo que me
interese para el modelado de sistemas que yo estoy haciendo. En cuanto a eso es la mirada y la
interpretación y la abstracción que voy a lograr.
Su definición como tal indica que la abstracción denota las características esenciales de un objeto que
los distingue de todos los demás tipos de objetos y proporciona fronteras conceptualmente nítidamente
definidas respecto a la perspectiva del observador.
Es entonces el pensamiento humano para
interpretar algo y crear un objeto e identificarlo en
un contexto o sistema. Al interpretarlo vamos a
separar e identificar las propiedades o
características esenciales de ese objeto para
poderlo reconocer, apreciar, ver cuál es el
comportamiento que tiene y por qué yo estoy
considerando esa característica y no otra. Esto es
debido a que son esas las características que me
interesan en el modelado del sistema que yo
quiero crear.
Encapsulamiento
Viene con el concepto de ocultar algo, encapsular
quiere decir que algo tapo. Lo que quiere ocultar
o tapar son los detalles de implementación de un
objeto, lo va a estar como protegiendo y lo que
hace esta forma de encapsular algo o de ocultar
los detalles es para poder facilitar el
manejamiento de la complejidad.
Solo se conoce el comportamiento que tiene el
objeto y no los detalles internos de cómo lo lleva
a cabo ni cómo se maneja.
La definición formal es el proceso de almacenar
en un mismo comportamiento, los elementos de
una abstracción y su implementación.
Análisis de Sistema Resumen Nicolás Aguirre
Modularidad
Es una forma de agrupar o empaquetar abstracciones en unidades discretas. Cuando vayamos
construyendo el sistema, vamos a crear un modelo y encontrar muchísimas clases. A mayor dificultad,
complejidad y dimensión que tenga el dominio del problema mayor es la cantidad de clases y esas
clases son el conjunto de objetos que comprende.
Cuando eso va tomando mucha dimensión, la mejor forma de poder manejar esa cantidad es agruparla
en partes más pequeñas. Eso significa la modularidad, empaqueta o agrupa abstracciones, estas
clases, en unidades discretas, en unidades más manejables.
Esta forma de agrupar busca cumplir con dos conceptos: el bajo acoplamiento y la alta cohesión.
Un sistema bien realizado busca lograr la menor dependencia entre las clases y los objetos de las
mismas (bajo acoplamiento) y una alta cohesión, es decir, que la definición de cada clase este con las
responsabilidades que le son propias.
La definición formal de modularidad es la propiedad que tiene un sistema que ha sido descompuesto
en un conjunto de módulos cohesivos y débilmente acoplados, es decir, bajo acoplamiento y alta
cohesión.
Mientras más bajo sea el acoplamiento, mejor se mantiene el sistema y mejor construido esta y
mientras alto sea el acoplamiento no es una buena construcción o un buen modelado. Si esa
construcción logra una alta cohesión estamos desarrollando un modelo que es bueno, que está bien
modularizado y si es baja la cohesión ahí el sistema tiene sus errores, sus falencias y debe ser
mejorado.
Jerarquía
Es una clasificación u ordenación de abstracciones. Yo voy a tener la identificación de clases, donde
se aplica el concepto de abstracción debido a que interpreto, ordeno, hago un esquema mental,
encuentro que eso es un objeto, le doy un nombre y por último agrupo en una clase todo el conjunto
de objetos que están con estructura y comportamiento común.
Cuando yo encontré una cantidad de clases, yo podría establecer una jerarquía que me permite
simplificar la compresión de un problema. Me permite identificar una clasificación u ordenar
abstracciones, ir de algo grande e irlo desarmando. De esta forma puedo manejar la interpretación que
hago de ese dominio, poderlo comprender y la jerarquía me permite simplificar esa interpretación o
comprensión.
Yo puedo tener jerarquía de clases o de partes, cuando hablo de clases hablamos del concepto de
herencia basado en la generalización. O tener jerarquía de partes, que son aquellas resueltas por esta
relación de tipo agregación o composición.
Jerarquía y herencia
Cuando yo identifique clases, podría empezar a trabajar como un concepto de herencia en donde voy
a tener algo superior (súper clase) y voy a tener algo inferior (sub clases) o también clase padre y
clase hijo que hereda comportamiento, es decir, definiciones que están dadas por algo superior. El hijo
hereda ese comportamiento y a la vez le agrega algo propio.
En la jerarquía de partes hay una relación todo/parte en donde en una clase le voy a dar una estructura
que va a formar un concepto de clase todo y va a tener un conjunto de elementos que va a formar la
Análisis de Sistema Resumen Nicolás Aguirre
clase que son partes. Las jerarquías pueden ser de clases o de partes, cuando sea de parte voy a
encontrar la relación de agregación o composición y lo que modela es un tipo de relación todo/parte.
Elementos secundarios
Los 3 elementos secundarios son tipificación, persistencia y la concurrencia.
Tipificación
Voy a tener muchos objetos de distinto tipo, entonces lo que va a hacer la tipificación es una forma de
agrupar los objetos del mismo tipo y que estos no pueden estar relacionados con objetos que no son
definidos.
La tipificación formalmente definida es la puesta en vigor de la clase de los objetos, de forma que los
objetos de tipos diferentes no pueden intercambiarse o pueden hacerlo de forma restringido.
Determina los comportamientos que pueda realizar y por lo tanto determina cuales son los mensajes
y operaciones validas sobre ese objeto.
Concurrencia
Es cuando a un mismo lugar acceden uno o más elementos. Es la propiedad que tiene un objeto de
poder manejar la llegada de distintas peticiones o manejar muchos eventos diferentes a la vez.
La definición formal es la propiedad que distingue un objeto activo de uno que no está activo y
concretamente es la capacidad de los objetos de poder actuar en el mismo momento ante diferentes
peticiones o se llaman solicitudes de servicios en forma concurrente y como puede asistirlas a todas y
ver que la primera petición es atendida y la que llego después no.
Persistencia
Se define formalmente como la propiedad de un objeto mediante la cual, su existencia perdura en el
tiempo y/o el espacio. La persistencia abarca la duración de los datos, es decir, que además de persistir
el estado de un objeto, también la clase debe trascender a cualquier programa individual. Así como
también un objeto una vez creado, consume la misma memoria física hasta que deja de existir.
Surgimiento de UML
Siempre que hay un cambio de paradigma, ese paradigma necesita el establecimiento de nuevas
teorías, nuevos marcos teóricos, nuevos fundamentos, nuevas definiciones. En esa creación de
paradigmas nuevos fue surgiendo UML
Los lenguajes orientados a objetos aparecieron entre mitad de los años 70s y fin de los 80s, siendo
que el número de métodos de OO (paradigma orientado a objetos) se incrementó entre 1989 y 1994 y
cada metodología tenía sus propias notaciones y simbología.
Como fue en aumento empezó a necesitarse
una unificación, debido a que había muchas
formas de representar lo mismo. Cada
metodología tenía sus propias notaciones y
símbolos, por eso se decía que estaba
fragmentados.
Análisis de Sistema Resumen Nicolás Aguirre
Esas 3 empezaron metodologías empezaron a destacarse, por tanto, esos 3 autores empezaron a
trabajar en conjunto y de ahí surge la UML en 1997.
¿Por qué modelamos?
En sistemas usamos los modelados, porque podemos representar la realidad y buscamos la forma de
representar simplificadamente la realidad y toda la propuesta de sistema se basa en una serie de
documentos que escriben o describen la propuesta y a la vez una serie de diagramas o modelos que
representan la propuesta del sistema que queremos hacer.
De esa forma podemos interpretar de la situación que estamos interpretando de esa realidad para
poder modelar sistemas dentro de esa complejidad.
UML
Su sigla significa El Lenguaje Unificado de Modelado, como es un lenguaje propone un vocabulario y
una serie de reglas para poder expresar algo y que se pueda comprender, porque como habla en el
mismo lenguaje, facilita la comunicación.
UML es un lenguaje estándar para escribir planos de software, nos ofrece un vocabulario para crear
una serie de modelo para poder escribir planos de ese software
Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la representación
conceptual y fisca de un sistema
UML permite crear los modelos considerando el paradigma orientado a objetos.
Objetivos del UML
Visualizar
UML me permite crear gráficamente una serie de diagramas que me permitan mostrar el sistema,
visualizarlo, y permitir la comunicación. El diagrama que haga una persona puede interpretarlo
cualquier otra porque está estandarizado.
Especificar
Los modelos permiten describir la estructura o el comportamiento de un sistema y son modelos
precisos, completos, no tienen ambigüedad y de esa forma yo puedo entender cómo funciona el
sistema.
Documentar
Cuando hablamos de documentar, siempre que hacemos una propuesta de sistema, de alguna manera
estos modelos documentan las decisiones de la propuesta que se está haciendo de cómo van a tener
la forma, los artefactos que vamos a construir (los productos). Va a permitir construir la documentación
de un sistema
Construir
No solamente es un lenguaje de modelado, sino que va a colaborar para poder transitar desde los
modelos a la construcción de sistema, a la codificación.
Análisis de Sistema Resumen Nicolás Aguirre
Otras consideraciones

Estructura de UML
En esa estructura se define:

Siendo:
Análisis de Sistema Resumen Nicolás Aguirre
Enlaces entre objetos
El sistema sería como una colección de objetos y estos colaboran entre si y contribuyen al
comportamiento de un sistema. Entonces, el sistema es una colección de objetos más lo que el sistema
hace (como colaboran entre si los objetos).
El enlace se entiende como una conexión física o conceptual entre objetos y de esta forma yo voy a ir
relacionando a los objetos. Cuando establezco un enlace voy a estar estableciendo una relación del
tipo cliente /servidor.
Se representa como una línea donde tengo un objeto 1 y un objeto 2 y establezco un enlace.
Que este una línea significa que hay un enlace, por lo que
puede mandarse mensajes a través de ese enlace.
Los mensajes están representados con una flecha dirigida
que representa la dirección del mensaje, quien lo dirige y
hacia quien va. Normalmente ese mensaje tiene una
etiqueta que dice que es lo que esta necesitando. A ese mensaje se lo entiende como una petición.
Los mensajes se muestran como líneas dirigidas que representan su dirección con la etiqueta que
nombra al propio mensaje. De esta forma hay objetos que reciben mensajes, reciben peticiones y
según como sea esa petición es cómo va a comportarse de alguna forma.
El objeto reacciona ante los mensajes que recibe. Cualquier acción que lleva a cabo el sistema se va
a iniciar a través del envió de una petición de un objeto “a” hacia el objeto “b” y ese objeto b es el
encargado de reaccionar a esa petición.
Las peticiones realizadas a los objetos son los mensajes y tenemos al que realiza el inicio de esa
petición se lo denomina cliente, que solicita un servicio, y a quien recibe es el objeto servidor, que es
quien recibe y provee el servicio solicitado.
Un cliente es cualquier objeto
que utiliza recursos de otro
objeto denominado servidor.
El comportamiento de un
objeto se puede caracterizar
como el servicio que presta a otros objetos. Así como a las operaciones que pueda iniciar sobre otros
objetos
De allí es que esta este concepto de la colaboración de objetos y que los objetos no están como
entidades aisladas por sí mismos, sino que tienen una definición propia, pero se conectan con otros
objetos y de esa forma logran establecer una serie de peticiones y comportamientos del sistema.
El comportamiento del sistema estará conformado por la colaboración entre todos los objetos del
mismo y por el envío y recepción de mensajes que es el conjunto de peticiones. El comportamiento
del sistema estará simulado a través del comportamiento de los objetos que lo componen de manera
que tal que un objeto primero envía una petición, ese objeto tiene una serie de métodos
(comportamiento del objeto) y va a estar encapsulado una serie de propiedades con sus valores que
es el estado del mismo y si puede resolver la petición hará un pedido de colaboración a otro objeto y
de esa forma va colaborando y van jugando los objetos entre sí.
Análisis de Sistema Resumen Nicolás Aguirre
El circulo grane es la zona publica que es
accesible desde otros objetos.
Esta zona publica que sería comportamientos
tiene encapsulado, tiene control sobre sus
datos, esa parte seria la zona privada que no
es accesible desde otros objetos.

Diagrama de clases
Lo que muestra un diagrama de clases es un conjunto de clases, así como sus relaciones. Es uno de
los diagramas más utilizados dentro del OO.
Este diagrama se utiliza para modelar lo que se conoce como la vista de diseño estática.
Este diagrama va a modelar la vista de diseño estática de un sistema o parte del mismo, porque a
veces el sistema es muy complejo y de mayor dimensión vamos haciendo vistas parciales, porque si
no sería muy complejo un diagrama donde estén todas las vistas integradas. Esta vista va a mostrar
una descripción de los atributos y del comportamiento que tienen esas clases.
Es muy útil para ilustrar relaciones entre clases e interfaces.
Clases
Cuando vamos a definir una clase, la simbología que propone UML es un recuadro formado por 3
partes:
El nombre de la clase tiene que ser representativo de lo que
contiene y que lo distinga de las otras clases. Tenemos una
notación para dar un nombre a las clases, siendo nombradas en
singular y la escritura será de una o más palabras donde la letra
primera de cada palabra va en mayúsculas y el resto de la
palabra se escribe en minúsculas. Va sin espacios, sin guiones y
sin otras cosas agregadas entre las letras.
Los nombres de los atributos tienen que cuando sea una o más palabra la primera palabra en
minúscula y la segunda en adelante primera letra en mayúscula y todo el resto en minúscula. Ejemplo:
“fechaDeNacimiento”.
Los nombres de las responsabilidades la forma de escritura es igual que atributos. Si hay una sola
palabra va en minúscula, si va más de una palabra de la segunda en adelante la primera letra en
mayúscula y el resto en minúscula. Ejemplo: “mostrarDatos()”.
Análisis de Sistema Resumen Nicolás Aguirre

Relaciones entre clases

Son las presentes dentro del bloque de construcción en la estructura de UML.
Asociacion
Se lo define como una relación estructural que especifica que los objetos de una clase están
conectados con los objetos de otra. Siempre que tengamos que establecer relaciones, al menos
tenemos dos clases y entre esas clases van a establecerse una relación.
Establece una relación de asociación primero haciendo una línea, una asociación denota una
dependencia semántica entre dos clases, pero no establece la forma exacta en la que una clase se
relaciona con la otra. Esto quiere decir que a la relación de asociación le voy a agregar el sentido de
la relación, y aso le llamamos la navegabilidad o navegación, que es, dada una asociación entre dos
clases se puede navegar desde un objeto de una clase hasta un objeto de la otra y eso establece el
sentido de la relación de una clase y de un objeto de una clase hacia otro objeto de otra clase.

Una asociación es la relación que se establece entre dos clases y el sentido de esta relación. De esta
forma yo estoy diciendo que un objeto es cliente estaría navegando, va a poder conocer a un objeto
de la clase categoría. Puede navegar desde el objeto de una clase hasta un objeto de la otra y como
ya establecí esa relación estructural digo que estos objetos están conectados. Esto es una relación de
asociación.
La multiplicidad nos va a establecer una cantidad indicando cuantos objetos de una clase pueden
conectarse a través de esta asociación con los objetos de la otra clase. Cuando tengamos que analizar
la relación entre clases, tendremos que ver para un objeto de la clase A con cuantos objetos o
instancias de la otra clase se puede relacionar y en función de eso se establece un valor mínimo, junto
con un valor máximo o puede ser un numero especifico o un rango de números concretos.
Siempre la multiplicidad se establece pensando, una vez establecida la navegabilidad, cuantos objetos
de la clase primera se puede relacionar con cuantos objetos de la clase segunda estableciendo una
relación.
Valor mínimo: puede asumir 0 o 1, que no tenga relación o que siempre exista al menos un objeto
relacionado 1 a 1.
Valor máximo: puede asumir al menos un valor 1, o sea un objeto de una
clase se relaciona con otro objeto de clase siempre y podría hasta haber
muchas relaciones, esa forma de mucho se puede escribir con la palabra
mucho, con un asterisco * o con una n.
Un número específico: hay un objeto que se relaciona con por ejemplo
dos objetos siempre o un rango de numero especifico, vamos del 1 al 8
por ejemplo, siempre se relaciona con esta cantidad.
Análisis de Sistema Resumen Nicolás Aguirre
En general cuando nosotros establecemos que una clase A se relaciona con una clase B es n sentido
único, por tanto, la asociación es unidireccional.

Hacia dónde va la flecha depende del dominio del problema y que conviene relacionar para que se
conozcan, cambiando rotundamente la relación cuando se relaciona una cosa con otra o viceversa.
También puede darse que es necesario que la relación sea en ambos sentidos, que a objetos de la
clase A conozcan a objetos de la clase B y viceversa. Cuando esto ocurre se habla de una relación
bidireccional. Esto se puede representar de dos formas, primero se establece la relación sin establecer
la navegabilidad, pero luego estableciendo la multiplicidad, o se las puede graficar por separado.

Agregación / composición
Cuando tengamos una relación de este tipo, vamos a estar en presencia de una relación que se llama
todo/parte donde a una clase vamos a representarla como algo que se llama mayor o más grande que
es el todo, que va a estar formado por elementos más pequeños que son las partes.
La simbología que vamos a tener es:
Tengo una clase 1 y clase 2, la clase que es el todo está en el
extremo donde está el rombo y en el otro extremo esta la clase
parte, en donde está el sentido de la relación. Se grafica con el
rombo en blanco, va a tener la navegabilidad que siempre va a
la parte y va a tener multiplicidad que siempre es mucho.
La composición respeta la misma definición, pero su graficacion
es un rombo relleno que inicia en la clase que es el todo y se
dirige a la clase que es la parte y también tiene una multiplicidad
de muchos.
Análisis de Sistema Resumen Nicolás Aguirre
Una agregación es un tipo de relación todo/parte en donde el tiempo de vida del objeto incluido (la
parte) es independiente del que lo incluye. También llaman a esta forma de agregación por partida,
porque es posible que un objeto parte o contenido corresponda más a un objeto todo o contenido.
Una composición lo que va a indicar es una relación entre dos clases y se denomina que es del tipo
“tiene un”, es decir, que un objeto del todo tiene objetos de la parte y siempre tiene que estar esa
estructura conformada en forma de estar representando un tipo de contención física. La parte no puede
existir si no está conformando en esta estructura el concepto del todo. Este objeto parte no es
independiente del objete todo que lo contiene y el tiempo de vida de ese objeto parte está condicionado
por el tiempo de vida del que lo incluye.
Generalización (Herencia)
Una relación de generalización lo que está demostrando o indicando es que tengo una relación del
tipo padre/hijo. La clase de las que otras heredan se denomina superclase y las clases hijas se
denominan subclases o clases hijas.
Simbología
La idea es que en la clase padre estén
los atributos comunes que van a ser
heredados por las clases hijas y las
responsabilidades que son comunes.
Las clases hijas van a tener una
definición de los atributos que le son
propios y el conjunto de
responsabilidades que también le son
propios.
Cada clase hija tiene las
responsabilidades y atributos
heredadas más las propias.
La herencia conceptualmente estaría representando una relación
entre clases en donde una clase comparte la estructura y/o
comportamiento definidos en una o más clases. Cuando está
definido en una sola clase padre estamos hablando de herencia
simple. Cuando está definida en una o más clases padre estamos
hablando de herencia múltiple. La herencia hace que esa
estructura de datos, la parte de atributos y responsabilidades
estén disponibles para su reutilización por parte de sus clases
hijas o subclases. Una clase hija puede añadir atributos o
responsabilidades a sus clases padres.
La herencia está asociada al concepto del polimorfismo que
significa que las responsabilidades de una clase hija que tiene la
misma “firma” (se ve más adelante) que una clase padre se
redefinen.
Análisis de Sistema Resumen Nicolás Aguirre

Autorrefrencia
La autorreferencia es una relación que una clase tiene hacia sí misma, se denomina dependencia
reflexiva. Gráficamente sería
Una autorreferencia sirve cuando tenemos
que indicar que para un objeto de una clase
tiene que tener relación con un objeto de su
misma clase. Ese es el concepto de
autorreferencia, cuando necesitamos
indicar para un objeto de la clase A, con
cuantos otros objetos tiene que
relacionarse con objetos de la misma clase
A. La autorreferencia usa una relación de
asociación. Se tiene que agregar esa
responsabilidad que permite esa relación.
Nombre de Rol
Es el nombre que se le da a la relación, se
usa para que quede más clara la relación
que se estableció. Siempre empieza con un
“+” adelante y un conjunto de palabras
pequeño, pero algo que permite entender la relación, algo que entienda el que lee el diagrama a que
se refiere esta relación. Puede ir en cualquier relación que uno establezca.
Patrones para el modelado de Software orientado a objetos
Los patrones se han ido creando en función de que otros profesionales de sistemas, al desarrollar
sistemas, ante un problema que iba ocurriendo en el desarrollo de sistema, establecía una solución.
Cuando empiezan a encontrar que de forma repetida ocurría un problema y se aplicaba la misma
solución, es donde empieza a surgir este concepto de patrones.
Análisis de Sistema Resumen Nicolás Aguirre
La idea es formular esas soluciones a problemas comunes para que los demás aprovechen.
Los patrones realizan una descripción de un problema que ocurre y de cómo solucionarlo dentro del
ámbito de los sistemas. Podemos reusar las experiencias, soluciones de análisis y diseño que ya
hemos aplicado anteriormente.
El patrón sugiere una solución,
pero va a depender de nuestro
análisis si para ese dominio en
particular ese patrón lo resuelve.
Un buen patrón propone una
solución al problema, provee una
serie de conceptos, permite derivar
soluciones desde primeros
principios, describe relaciones y
debe tener en cuenta el
componente humano.

Patrones para la construcción del modelo de objeto del dominio

Patrón fundamental
El patrón fundamental plantea el concepto de lo que significa lo que es un patrón y ayuda a pensar
para que nosotros podamos, cuando hacemos el diagrama de clases, que clases se pueden relacionar,
en función de una concepción de esa clase que atributos y responsabilidades podría tener. De allí que
el patrón orienta, sugiere para una situación de clases que corresponden a un concepto cuáles son los
atributos y responsabilidades, cual relación podrían tener, de qué tipo y que multiplicidad podría existir.
Uno no aplica el patrón de forma directa, sino que analiza la situación real y aprovecha de ese patrón
lo que sugiere y en ese dominio particular aplica lo que le sirve, lo que mejor este definido para modelar
esa solución.
El patrón fundamental es la plantilla que todos los patrones siguen, los otros patrones del modelo de
objeto son variaciones de este tema. Propone una clase primera “A” y una clase “B” y propone una
Análisis de Sistema Resumen Nicolás Aguirre
serie de atributos y responsabilidades para cada clase de forma genérica, también puede proponer
relaciones, por ejemplo, bidireccionales y también multiplicidad.
Patrones transaccionales
Cada conjunto de patrones va a plantear un conjunto de patrones de grupo, establece que podríamos
encontrar en un dominio concreto con clases que podrían pertenecer a alguno de los conceptos que
propone.
Yo voy a ir encontrando clases en una situación particular y luego voy a ver los patrones y voy viendo
ese concepto que yo identifique con qué tipo de concepto de clases o patrón podría estar asociado.
Vamos encontrando clases y tratamos de ver si
existen patrones que representen el concepto
identificado.
Si se corresponde con uno de los conceptos se
aplica lo que se sugiere el patrón.
Puede haber dominios donde no se tenga relación
directa con patrones. Este modelo no distingue
composición o agregación porque no está
actualizado a composición en lo nuevo de UML.
Esta numeración establece una lista de posibles
categorías de patrones transaccionales
asociando de a dos clases conceptuales entre sí.
Por cada par de clases relacionadas, se nos
presenta una planilla, que indica los posibles
atributos responsabilidades, relaciones,
multiplicidades y las posibles combinaciones.
Análisis de Sistema Resumen Nicolás Aguirre
Patrones de agregación
Funciona de la misma forma que los patrones transaccionales.

Ejemplo:

Modelados del dominio

Cuando modelamos el dominio vamos a con todo lo que vimos antes y considerando todo el modelado
de negocio y todo el listado de requerimiento vamos a construir considerando la concepción de
paradigmas orientado a objetos y todas las definiciones de clases y objetos.
Para que el diagrama llegue a ser un buen modelo se aplican los patrones estructurales que nos
orienta, nos sugieren y nos dan pauta para un dominio particular que clases considera y que atributos,
responsabilidades, que relaciones y que multiplicada tener en cuenta.
Ahora volvemos a la unidad 2 para completar la parte de metodologías agiles teniendo en cuenta lo
visto en paradigma orientado a objetos.

Metodologías Ágiles
Análisis de Sistema Resumen Nicolás Aguirre
Como el desarrollo de sistema empezó a demandar otra forma de trabajar para responder el cómo iba
cambiando los requerimientos del cliente y que la tecnología actual no permitía, empezó a surgir una
nueva forma de atender esa necesidad cambiante de requerimientos en un cliente y por otro lado el
ofrecer a ese cliente un desarrollo más rápido del software
Por tanto, se establecieron una serie de pautas en 2001 que definieron el termino ágil en el manifiesto
ágil.
Se estableció un concepto, en este proceso de desarrollo iterativo e incremental, de que cada iteración
va a ser un ciclo y en esa iteración van a realizarse todas las actividades para el desarrollo de un
sistema, actividades genéricas. Entonces una iteración en este proceso ágil incluye tareas de
planificación, de análisis de requisitos, de diseño, de codificación, de prueba y de documentación. No
ignora esos pasos, los ejecuta, pero lo que cambia es la forma en que trabaja y la velocidad del
resultado. Además, empieza a incorporar el concepto de finalizado, va teniendo un conjunto de tareas
y le va dando un resultado.
La idea es que cada iteración va a ir trabajando agregando una funcionalidad al sistema para luego
poderlo lanzar o ponerlo en producción o puesta en marcha y de esa forma va logrando un incremento
en el valor que va logrando de ese sistema, entonces el software va siendo construido en forma
incremental. En ese desarrollo ya está probado, validado y se entrega un producto sin errores y listo
para utilizar.
Características de esta metodología
Esto es muy útil
porque al inicio el
cliente no tiene una
idea totalmente clara
de lo que quiere y a
medida que se va desarrollando el sistema el cliente va afinando lo que necesita y lo va mejorando o
modificando. Si lo que ve no es lo que a él quiere ir entonces va planteando cambios de requerimiento
y el sistema perfectamente se adapta y la dinámica de trabajo y el proceso de desarrollo se adapta a
esos cambios sin generar impactos graves, grandes costos o mucho trabajo.
Conforme avanza el proceso involucramos al
cliente en definir prioridades, ir validando cada
cosa que vamos desarrollando de manera tal que
el impacto va a ser menor cuando yo le dé el
software programado porque ya estuvo
participando en el desarrollo y avance del sistema,
a diferencia del tradicional donde el cliente dice que quiere al inicio y se lo muestra todo listo al final y
si no le gusta hay mucho retrabajo.
El cliente ve resultados más rápido, lo que lo
mantiene más conforme y contento.
Análisis de Sistema Resumen Nicolás Aguirre

Auto organizado significa que va a establecer una forma de trabajo donde van haciendo planificaciones
cortas, se reparten las tareas, van avanzando y a la vez esta forma es auto-organizada, justamente el
equipo define que funciones va a abarcar, como va a avanzar y de qué forma se reparten las tareas.
Son estos mismos integrantes multidisciplinarios, pueden hacer tareas tanto de análisis, diseño,
implementación, prueba y pueden participar en todas las distintas acciones que toca al desarrollar un
sistema. Participen en toma de decisiones a corto plazo, de cómo van avanzando en cada iteración y
cada parte que van desarrollando en el sistema.
Manifiesto por el desarrollo Ágil de software
Son las reglas e ítems que definen a esta metodología.
Ellos se enfocan más en valorar
individuos e interacciones y que los
equipos sean auto-organizados y
multidisciplinarios que en procesos y
herramientas que son más
burocráticos.
Se enfocan en lograr software
funcionando más rápidamente sin
documentación excesiva.
La idea es que el cliente participe y
colabore durante el desarrollo
completo del sistema.
Se enfoca en la respuesta ante el
cambio de requerimiento, antes que
seguir un plan.
Análisis de Sistema Resumen Nicolás Aguirre

Heurística: conjunto de técnicas o métodos para resolver un problema.

En definitiva, la diferencia es que las metodologías agiles buscan distintos métodos para resolver un
problema a través de resolver más rápidamente con un software, lograr resultados a través de la
construcción del software. Las tradicionales por allí tienen también normas provenientes de
estándares, pero su proceso para desarrollar el sistema es un poco más lento.
Las agiles están preparadas para el cambio, la tradicional tiene más resistencia ante ellos.
En metodologías agiles tenemos una serie de reglas y coordinación que el equipo en forma interna
define, en la tradicional tenemos el líder de proyecto y una gestión que está dispuesta externamente y
el equipo de integrantes trabajan conforme a esas reglas establecidas externamente.
Tienen procesos menos controlados en la parte de agiles, a diferencia de las tradicionales que son
más burocráticas al tener mayor cantidad de pasos, lo que le da lentitud.
El cliente colabora en las metodologías agiles, en la tradicional no, y etc.
Análisis de Sistema Resumen Nicolás Aguirre
Distintas metodologías ágiles
XP (Extreme Porgramming)
Su fundador fue Ken Beck. Propone detectar las necesidades del cliente, rápidamente codificar,
mostrar el código y en función de eso ir logrando el resultado y avance en el sistema.
Explicación de las características no
tan obvias:
Busca un desarrollo iterativo e
incremental, trabaja con pruebas
unitarias continuas cuando uno va
desarrollando un sistema va
codificando y haciendo pruebas para
ver si funciona (pruebas unitarias) y
como lo hace de manera continua
verifica que siempre funcione.
Se trabaja con programación en
parejas, donde uno programa una
parte otro otra parte, y entonces se
integran, cotejan y corrigen.
Hay una refactorización del código
(mejora y actualización).
No suele usar mucha
documentación, queda más en lo
verbal y en el resultado logrado con
el cliente.
Ciclo de vida de este
tipo de metodología
ágil.
Análisis de Sistema Resumen Nicolás Aguirre
Kanban
Es una palabra japonesa que significa tarjetas visuales, esto surge hace varios en Toyota, en donde
para la producción de todo lo que es Toyota definieron una tabla grande en donde se establecía como
estaba el equipo trabajando, cuales tareas estaban iniciadas, cuales no y cuales se habían terminado.
Actualmente se aplica en la gestión de proyecto de software. Es útil para representar visualmente lo
que se está realizando en un proyecto, lo que está pendiente y lo ya realizado.

Kanban puede ser mejorado, incluyendo más columnas, como pendiente, desarrollo, test, y demás
con tal de lograr representar visualmente el desarrollo del sistema.
Scrum
Es otra metodología agiles que más se utiliza actualmente en el mercado, le compite a UML.
Análisis de Sistema Resumen Nicolás Aguirre

UNIDAD 4: INGENIERÍA DE REQUERIMIENTOS

Repaso de requerimientos
Nosotros siempre que tenemos que proponer un sistema de información y luego desarrollarlo debemos
comprender la naturaleza del problema, atendiendo la complejidad de la problemática y
descomponiendo el problema para poderlo manejar y en esta descomposición y análisis de la
comprensión del problema nos permite encontrar de forma más acertada los requerimientos.
Para proponer y desarrollar un sistema de información se debe comprender la naturaleza del problema,
esto puede ser muy complejo, especialmente si el sistema es nuevo. Cuando nos toca desarrollar
sistemas puede ser que partiésemos desde cero, el cliente ya tenga un sistema que quiera reemplazar
o viene haciendo sus procesos de forma manual y quiere automatizarse o a veces tiene una
proyección, etc. Tenemos que estar en capacidad de entender la situación de ese problema y el
contexto de la necesidad de ese problema.
A veces es difícil saber desde un inicio exactamente lo que el sistema debe hacer, la realidad en la
construcción de sistema es que tenemos una idea general y cierto detalle de lo que el sistema debe
hacer, no se tiene desde el principio definido a todo lo que tiene que hacer. Esto será un
descubrimiento con el cliente conforme avance el desarrollo de la propuesta con ese cliente.
Cuando yo voy pensando en lo que el sistema debe hacer hay detalles que no tengo hasta que no
profundizo en ese tema, es difícil saber en forma exacta lo que el sistema debe hacer, se tiene una
noción, pero no los detalles exactos que se irán encontrando a medida que se estudia el problema.
Debe poder detectase todas las necesidades del cliente. A veces si tiene claro lo que quiere, pero no
el detalle, entonces, si a veces no toma buenas decisiones porque le falta información estadística
capaz no tiene tan en claro que información necesita, pero finalmente esa información termina siendo
necesidad de un cliente. Nuestro trabajo como analistas es fundamental poder encontrar los
requerimientos de sistemas teniendo en conocimiento toda esta problemática habiendo un trabajo de
elaboración, de descubrimiento y crecimiento conforme va evolucionando el sistema.
Un requerimiento es una característica del sistema que va a estar acompañada por una descripción
de algo que el sistema es capaz de hacer considerando restricciones y servicios que el mismo debe
considerar con el fin de satisfacer el propósito del mismo o el propósito del mismo.
Cuando debamos encontrar requerimientos y plantear todas esas características debemos tener en
cuenta:
Definición del estándar IEEE
Define a un requerimiento como una
condición o capacidad requerida por un
usuario para resolver un problema o lograr
un objetivo para resolver un problema o
lograr un objetivo.
Es una condición o capacidad que debe
cumplir o poseer un sistema para satisfacer
un contrato, estándar, especificación u otros
documentos de imposiciones formales.
Análisis de Sistema Resumen Nicolás Aguirre
Es una representación documentada de una condición o capacidad.
Propósitos de los requerimientos
Los roles de un sistema de información son los analistas de sistema, los diseñadores, los
desarrolladores, el equipo de pruebas (testing).
Los requerimientos según el rol que tengan en el sistema tienen una finalidad más especifica.
Por un lado, va a permitir a los analistas de sistema que expliquen como han entendido lo que el cliente
pretende del sistema.
Cuando continuamos desarrollando un sistema además de plantear ese listado también va a servir
para construir una serie de modelos y permite a los diseñadores y desarrolladores (programadoers)
saber cual es la funcionalidad que tienen que hacer, las restricciones a considerar y todas las
características para el sistema resultante. Los diseñadores crearan un modelo en la etapa de diseño,
los desarrolladores y programadores van a codificar el sistema en función de esa necesidad que tienen
que cubrir.
Finalmente, para aquellos que ejercen el rol de testing o de ejecutar las pruebas de un sistema le va
a servir para saber qué comprobaciones tienen que llevar a cabo, para ver si lo que el cliente quiere y
lo que la propuesta hizo es consistente, si el desarrollo del sistema cubre esos requerimientos y las
necesidades que planteo dicho cliente.
Problemas de los requerimientos
Los requerimientos, así como el cliente los cuenta o como estos futuros usuarios los cuentan no son
tan claros y perfectos, suelen ser imprecisos, ambiguos, contradictorios y/o erróneos. Nosotros cuando
nos vamos encontrando con los requerimientos tenemos que saber hacer un análisis para refinarlos,
revisarlos y para quitarles ambigüedad y contradicción.
Por otro lado, pueden estar desorganizados porque cada uno va planteando cosas dentro de una
secuencia de procesos de negocio, situaciones desorganizadas y en ese planteo e identificación
tenemos que darles un orden en una secuencia lógica de ocurrencia y es una correspondencia
marcando cual requerimiento debe ocurrir primero y cual consume o necesita un requerimiento
anterior.
No siempre se conocen las verdaderas necesidades de lo que quiere el cliente de lo que debe hacer
el sistema, confundiendo cuestiones personal o necesidades en función de su trabajo que no es lo
mismo que un requerimiento o una necesidad de un sistema. Cuando uno va a trabajar con el
descubrimiento de los requerimientos se presenta un poco de todo lo anterior mencionado, por eso la
captura de requerimientos es un proceso continuo porque a medida que se trabaja con el cliente se
van refinando, adecuando a lo que el sistema debe hacer.
Características de los requerimientos
Todo requerimiento debería ser necesario, que quiere decir que para esa propuesta ese requerimiento
no se puede omitir y si se omitiera estaría como incompleto e ineficiente el sistema.
Debe ser conciso teniendo definido una forma tal que sea fácil de leer y de entender, no largas
oraciones o párrafos para plantear un requerimiento, siendo claro.
Análisis de Sistema Resumen Nicolás Aguirre
Debe ser completo porque tiene que ser bien entendido y comprendido. Debe ser consistente y eso
se da cuando no tiene contradicción con otro que está en el listado de la identificación de los
requerimientos.
Debe ser no ambiguo dando claridad de lo que el requerimiento quiere expresar no admitiendo distintas
interpretaciones dando una única interpretación
Debe ser verificable que significa que cuando yo deba evaluar si los requerimientos se están cubriendo,
a ese requerimiento, así como está planteado yo lo pueda cuantificar de una manera tal que pueda
verificar si se cumple no existiendo diferentes métodos de validación.
Niveles de descripción de requerimientos
Cuando uno detecta una serie de requerimientos, estos se definen en dos niveles en función de como
estén escritos los mismos, siendo requerimientos del usuario y requerimientos del sistema.
Cuando nos toque construir un documento en función de si esta dirigido al usuario podemos tener una
forma de describirlo que está escrita en modo de requerimientos del usuario y cuando necesitamos
plantearlos y que le sirva al equipo de sistema para otro tipo de funciones y detalles es cuando el nivel
que vamos a tener de esa descripción va a estar planteado como requerimientos del sistema.
Requerimientos del usuario
Documenta los deseos y necesidades del cliente, y se expresa en un lenguaje claro para el siendo
declaraciones u oraciones más breves y concretas en un lenguaje del cliente porque están orientados
en forma primaria para la comunidad del cliente siendo esa la audiencia primaria
Son declaraciones en lenguaje natural y en diagramas de los servicios que se espera que el sistema
provea y de las restricciones bajo los cuales debe operar.
Eso es lo que se denomina audiencia primaria para los requerimientos C (del cliente).
La audiencia secundaria es la comunidad del desarrollador y del equipo de desarrollo del sistema.
Requerimientos del sistema
Este tipo de descripción o nivel considera una forma mas detallada y estructurada de relatar o describir
servicios y restricciones del sistema, siendo estos los requerimientos funcionales y no funcionales
respectivamente
El documento de requerimientos del sistema algunas veces denominado especificación funcional,
debe ser preciso. Sirve como una especie de contrato entre el comprador del sistema y los
desarrolladores.
La audiencia primaria en este caso es la comunidad del desarrollador (profesional del sistema) y la
comunidad del cliente es la audiencia secundaria.
Análisis de Sistema Resumen Nicolás Aguirre
Nivel de descripción de los requerimientos
La relación entre los dos niveles de descripción de los requerimientos y su definición va a formar un
documento estandarizado y que tiene como sigla la ERS (Especificación de Requisitos de Software) y
también existe un estándar que
establece como se puede formar el
documento que sirve a modo de
contrato entre el cliente y el equipo
de sistema en donde se resumen
los documentos que se
encontraron, realizando la
propuesta formal del sistema y
normalmente este documento que sirve como modo de contrato sirve para acordar entre las partes la
propuesta del equipo del sistema con la necesidad de un cliente.
Tiene 4 partes principales siendo la primera de introducción, la segunda de descripción general donde
se pueden escribir requerimientos de usuario/cliente. Tercero viene la sección de requerimientos
específicos donde se pueden incorporan los requerimientos del sistema con todo el detalle de los
mismos y una sección cuarta que es información de soporte con toda la información o diagrama que
se necesite agregar en ese documento.
Clasificación de los requerimientos no funcionales

El autor de este cuadro trata de organizar todos los requerimientos no funcionales en tres grandes
categorías tratando de consignar todo el universo posible para identificar los mismos como son: los
requerimientos del producto, los requerimientos de la organización y los externos.
Cada uno los divide en subconjuntos de posibles requerimientos a considerar en cada una de esas 3
categorías.
Análisis de Sistema Resumen Nicolás Aguirre
Para requerimientos del producto considera requerimientos de eficiencia, de confiabilidad y de
seguridad y dentro de eficiencia subdivide en requerimientos de rendimiento y de espacio. Cuando
hablamos de requerimientos de producto estamos hablando del sistema, el producto es un resultado
de la realización de esta tarea del desarrollo de un sistema termina siendo un artefacto, cuando
pensamos en el producto y buscamos requerimientos no funcionales podrían estar en algunas de estas
posibilidades.
Por otro lado, también tiene una segunda categoría que son los requerimientos de la organización que
se subdivide en requerimientos ambientales, operaciones y de desarrollo. En requerimientos externos
consideramos regulatorios, ético y legales que se subdivide en requerimientos contables y de
protección /seguridad.
El hecho de que haya distintos niveles no quiere decir que tenga uno mayor importancia que el otro,
si no que muestra como se ha ido ordenado en distintos espacios el subconjunto que comprende las
tres categorías, pero no es mayor o menor importancia el cómo están desglosados.
Requerimientos del producto
Consideramos todo lo que tenga que ver con el comportamiento de ese producto, del sistema
resultante. Cuando hablamos de requerimientos de eficiencia que comprende rendimiento y espacio
podemos encontrar requerimientos que hablen de la velocidad de ejecución cuando hablamos de la
velocidad de un procesador, de la capacidad de memoria cuando nos referimos al tamaño del disco,
en esas situaciones estaríamos en ejemplos de eficiencia.
Por otro lado tenemos requerimientos de confiabilidad que hablan de fallas del sistema en función de
la posibilidad de ofrecer soluciones antes fallas, que tipo de backup tenemos y que tipo de seguridad
de los datos, además de la confiabilidad en los mismos.
Cuando se habla de requerimientos de seguridad son accesos al sistema, formatos clave de usuarios,
cuando decimos que la clave de usuario tiene que ser de una determinada forma como tantos
caracteres, una mayúscula, etc. nos referimos a aspectos que atienden la seguridad dentro de un
producto.
Cuando se habla de requerimientos de usabilidad habla del uso, del futuro usuario como usara el
sistema, colores de la pantalla estaría en la categoría, tipo de letras, tamaño de la misma donde estará
ubicado, todo lo que detalle como se debe ver y mostrar las cosas en el sistema en pantallas o recortes
estamos hablando de criterios de usabilidad, estando dentro de la categoría de producto.
Requerimientos de la organización
Son políticas y procedimientos existentes en la organización del cliente y en la del desarrollador.
Cuando se habla de requerimientos operacionales define como se utiliza el sistema.
Cuando hablamos de requerimientos del proceso de desarrollo, se refiere a que lenguaje de
programación, que entorno, si será web o Mobile, son restricciones que orientan a requerimientos de
la organización porque a veces el negocio tiene una serie de equipamientos y un sistema operativo
funcional y quiere que el sistema se adapte a ese entorno diferente, hay varias cosas que se deben
ajustar en ese sentido.
Cuando hablamos de requerimientos ambientales que define el entorno de operación del sistema.
Análisis de Sistema Resumen Nicolás Aguirre
Requerimientos externos
Esta clasificación cubre todos los requerimientos que se derivan de los factores externos al sistema y
de su proceso de desarrollo.
Cuando hablamos de requerimientos regulatorios que definen lo que debe hacer el sistema para ser
aprobado en su uso por su regulador como por ejemplo el banco central
Cuando hablamos de requerimientos legislativos se refiere a aquellos que deben seguirse para
asegurar que el sistema opere dentro de la ley, son externos porque los establece una unidad externa
a la organización.
Cuando hablamos de requerimientos éticos se refiere a aquellos que aseguran que será aceptado el
sistema por el usuario y por el público en general, se usa este concepto cuando se quiere minimizar el
uso de papel por cuestiones ambientales y ese tipo de cosas.
El proceso de la ingeniería de requerimientos
Se define a la ingeniería de requerimientos como un proceso en el cual vamos a descubrir, analizar,
documentar y verificar los servicios y restricciones que debe considerar el sistema a desarrollar. En
este proceso de descubrir requerimientos o servicio y restricciones (que también son requerimientos)
va a ver como una serie de actividades que nos permiten descubrirlos, y cuando decimos de analizar
si son verdaderos requerimientos, considerar todas las características como que no sea ambiguos y
demás, recién en ese momento los podemos documentar y también vamos a verificar trabajando con
el cliente para ver si lo detectado, analizado y documentado es lo que el quiere. En eso consiste la
ingeniería de requerimientos.
De esta forma vamos a lograr como resultado de este procedimiento o proceso, una especificación de
los requerimientos que sea completa, consistente y no ambigua. La misma va a servir a modo de
contrato, de acuerdo, entre las partes involucradas y que participan en el desarrollo de un sistema, por
un lado mi cliente y futuro usuario perteneciente a esa organización, negocio y por otro lado el equipo
de profesionales que desarrollaría el sistema para que sirva a ese usuario.
Actividades de la ingeniería de requerimientos
Nuestra tarea principal de nuestro trabajo es partir de la identificación correcta de los requerimientos
porque va a guiar el accionar del sistema. Lo
consideraremos de forma general y hasta cierto
nivel de detalle, dándose la profundización a
medida que se va avanzando en la profundización
de esos requerimientos y en la interacción con el
cliente de modo tal que existen una serie de
actividades que permiten desarrollar este
proceso, estando en un contexto que es el
dominio del problema que es la situación de
estudio del negocio, de esa realidad.
Se parte siempre del usuario entendido como el cliente a futuro que hará uso del sistema, a partir de
interactuar con ellos se detectan los requerimientos del mismos, llevando a cabo la primera actividad
conocida como elicitación donde se realiza esta búsqueda y descubrimiento de los requerimientos. EL
resultado de esa elicitación nos da un conocimiento de ese conocimiento, de esas necesidades,
problemáticas, a donde debo orientar el sistema planteando los requerimientos y especificándolos.
Análisis de Sistema Resumen Nicolás Aguirre
En la especificación voy conformando un listado de requerimientos, los clasifico y documento en un
formato especifico que es la ERS. Dentro de esta actividad, la que nos va a permitir interactuar con el
futuro usuario y ver si lo que propongo va acorde a lo que necesita es la actividad de validación, se
construye un documento y modelos de requerimientos, teniendo que trabajar con el usuario validando
esos modelos. Vamos a tener una retroalimentación de ese usuario donde que le sirve, que no, le
ajusta el requerimiento, le agrega cambios , le hace la devolución de modo tal que se debe revisar lo
que identifique, lo que describí, la especificación y ajustar todo en función de buscar nuevo
conocimiento, o reformular, cambiar lo que ya está, todo en función de ir cubriendo las necesidades y
todo lo planteado por ese usuario obteniendo un documento que es la especificación de los
requerimientos completa y validad con el usuario pero en una construcción continua , va acompañando
al desarrollo de un sistema.
Elicitación
Es justamente la primera actividad en donde descubrimos los requerimientos, se la define como el
proceso donde se adquiere el conocimiento del trabajo del cliente o futuro usuario, se comprenden sus
necesidades, se detectan las restricciones medio ambientales y vamos encontrando los
requerimientos.
El resultado de esta actividad va a ser el conjunto de los requerimientos de todas las partes
involucradas. Podrán ser escrito los requerimientos del usuario o sistema, o también se puede escribir
el listado de requerimientos funcionales o no funcionales.
Para poder realizar esta actividad vamos a usar una serie de técnicas conocidas como entrevistas,
cuestionarios, observación, análisis de documentos, torbellino de ideas.
Especificación
Toda esa información, ese conocimiento que brinda la elicitación donde modelamos el negocio
conociendo como funciona, se toma esa información pasando a esta etapa de especificación donde
haceos análisis de lo detectado y lograr describirlos, especificarlos. La especificación es un proceso
donde se describe el requerimiento.
El resultado termina siendo el documento denominado ERS que es una forma de contrato entre el
futuro usuario y los desarrolladores, donde se describe el funcionamiento deseado del software y las
otras restricciones, no mostrando como será alcanzada tal funcionalidad. Cuando hablamos de
especificación y de ingeniería de requerimientos hablamos de que debe hacer el sistema y no como
debe hacerlo, porque hacemos el análisis, no modelamos el diseño.
Las técnicas usadas para especificar es la denominada casos de usos.
Validación
En esta actividad vamos a contrastar con el cliente si lo que estamos pensando, esos casos de usos
que encontramos, esos prototipos que diseñamos y los datos que estamos manejando, es lo que
cliente necesita, o si no hare ajustes en función de su retroalimentación, haciendo cambios necesarios
ajustando la especificación de modo tal de estar alineado con lo que quiere el cliente. La ingeniería de
requerimientos trabaja este proceso de elicitación, especificación y validación antes de pasar a la etapa
de programación, de diseño del sistema de manera tal de ir desde ya detectando cambios,
necesidades nuevas del cliente y conforme vamos avanzando en el desarrollo se va trabajando sobre
funciones validadas, prototipos validados y sobre acciones que contrarreste con el cliente sabiendo
que voy por el camino correcto.
Análisis de Sistema Resumen Nicolás Aguirre
La validación es el proceso que certifica que se ataca e problema correcto. Este proceso final se nutre
de los anteriores y realiza la integración y validación final de lo obtenido en cada una de las etapas
anteriores.
El resultado de esta validación es el modelo de requerimientos ya validado en línea con las
expectativas de los usuarios.
Existen distintas técnicas para hacer esta validación, siendo tres las principales, conocidas como
revisiones de requerimientos, prototipos de interfaz, o la generación de casos de pruebas.
Procesos de la ingeniería de requerimientos
Este proceso se realiza como un proceso iterativo, el desarrollo de un sistema siempre va a ser iterativo
e incremental no habiendo una forma donde todos los requerimientos sean conocidos desde un inicio,
estando bien claros. Lo natural y demostrado es que el cliente tiene la necesidad, sabe que quiere,
pero el detalle se obtiene a partir de que vamos avanzando en el desarrollo del sistema y el cliente va
viendo que puede hacer el sistema, que datos manejas y que puede hacer en el sistema, surgiendo
cambios en lo requerimiento o una necesidad de nuevos.
Se usa una gráfica en forma de espiral
que tiene 3 cuadrantes, empezando en
el centro, siendo el primer cuadrante el
de obtención de requerimientos
(elicitación) y vamos creciendo en la
especificación, vamos validando y
conforme va creciendo se obtiene
nuevos requerimientos, cambios o
ajustes y si continuamos tenemos más
información vamos especificando,
hacemos prototipos y de esta forma va
creciendo.
El estudio de viabilidad se remonta a la
primera propuesta que se ofrece
siempre se tiene que hacer ese análisis
de prefactibilidad que ya se trató en
otro momento en este apunte. Es un
análisis sencillo desde un inicio de si es
viable o no lo que se propone. Se hace
al principio porque si estoy proponiendo algo que no tiene viabilidad, el sistema se interrumpe y corta
allí, lo que se busca es verificar si el proyecto se puede realizar con éxito. El de prefactibilidad es mas
general, contemplando estos aspectos técnicos, económicos y operativos, con un detalle no tan
profundo. Conforme avance el proyecto, tenga otras variables, sea muy complejo puede llegar a
necesitar un estudio de viabilidad mas profundo.
De esta forma trabaja el proceso de ingeniería de requerimientos, siendo espiralado e iterativo.
Rol del modelado de requerimiento en la ingenria de requerimientos
Se parte de encontrar una serie de fuentes de información con personas, sistemas, documentos,
teniendo un conocimiento de esa realidad, negocio u organización encontrando datos. Vamos a buscar
Análisis de Sistema Resumen Nicolás Aguirre
modelar todos esos requerimientos, hacemos un análisis, los clasificamos, planteamos, empezamos
a construir una serie de modelos, se identifican casos de usos, se describe las funciones del sistema
diseñando prototipos, siendo toda esta tarea lo que se denomina la especificación de requerimientos
y vamos a validar con el cliente, constatando lo que quiere con como vamos, siendo todo un ciclo en
espiral hasta que se obtiene un modelo de requerimientos, siendo al ERS donde se detalla la
propuesta, funciones, estructuras de los datos y comportamiento del sistema y la descripción del
mismo y los prototipos que diseñan el mismo.
Lo que busca la ingeniería de requerimientos es tratar de detectar correctamente esos requerimientos,
crear los modelos que describan y cubran esos requerimientos y validarlos con el cliente previo a que
se pasa a las siguientes actividades de programación y diseño, de manera tal de minimizar errores
conforme se avance en el proyecto, anticipándose el cliente y sabiendo que lo que quiere es lo que va
a ver.
UNIDAD 5: ELICITACIÓN
Es el proceso de descubrir, analizar, documentar y verificar los servicios y restricciones que debe
considerar el sistema a desarrollar.
Es el proceso donde nosotros vamos a adquirir todo el conocimiento de como hace su trabajo y que
acciones realiza el cliente y nuestro futuro usuario, de esta forma buscamos comprender sus
necesidades, como obtiene el conocimiento del problema y vamos encontrando las restricciones medio
ambientales.
En este proceso se busca descubrir los requerimientos y la idea va a ser establecer mucha
comunicación con esos clientes/usuarios y buscar información y analizarla y allí es donde voy a ir
encontrando todas las acciones como las hace, todo lo que me va trasmitiendo de que necesita, todo
aquello que me brinde información para ir encontrando problemática, necesidades y entender el
funcionamiento de todo. Por eso de esa forma vamos adquiriendo el conocimiento sobre ese producto
a desarrollar.
Se incorpora este conocimiento del negocio, por eso es de vital importancia conocer e interpretar como
funciona porque el sistema que voy a desarrollar y los requerimientos que van a ser el disparador para
desarrollar ese sistema tiene que cubrir las necesidades de ese negocio de ese cliente. Por eso es
importante conocerlo en forma correcta porque sino modelamos en forma errónea.
Esta actividad esta relacionada a la adquisición y análisis de requerimientos, también conocida como
elicitiación.

Propósito de la elicitación
Es obtener el conocimiento relevante del problema, de la situación de ese dominio del problema para
que podamos producir o generar una especificación, una descripción rigurosa, correcta y completa de
software necesario para resolver ese problema
Actividades
Dentro de las actividades que se llevan a cabo para la elicitación se enuncian las siguientes tres:
Análisis de Sistema Resumen Nicolás Aguirre
cuando nosotros vamos descubriendo esos requerimientos hacemos parte del análisis en el cuál
vamos a clasificar y organizar esos requerimientos en un orden lógico y vamos a clasificarlos cuales
si y no teniendo en cuenta si son funcionales o no funcionales y también vamos a priorizar y negociar
los requerimientos porque puede ser que el cliente una gran cantidad de funciones, por ello, una vez
identificados los requerimientos vamos a negociar cuales vamos a abarcar y cuales priorizar para
arrancar con ellos y dejando otros para después (la priorización es el orden en el cual se van a ir
atendiendo, resolviendo, programando y desarrollando de forma completa esos requerimientos).
Interacción con otras actividades de la ingeniería de requerimientos
Esta tarea de elicitación habíamos visto en el grafico que actúa mucho con especificación y validación,
siendo la misma que la tarea de descubrir estos requerimientos y conocer ese contexto y situación real
va a proveer de toda la información que se deberá especificar. Todo ese conocimiento que tenemos
sobre el dominio va a generar necesidades de validación porque voy a contrarrestar con el cliente para
saber si lo que detecte como requerimiento y la propuesta que estoy resolviendo va acorde a lo que
necesita.
En ese proceso de variación y este feedback que tengo con el cliente puedo llegar a encontrarme con
nuevos requerimientos, nuevas necesidades que el cliente me plantea y que yo lo voy a tener que
considerar para volver a hacer una nueva elicitación, nueva especificación agregando esto y dándole
tratamiento a esos nuevos requerimientos además de modificar lo que resulto de la validación de los
requerimientos que están especificados y descritos.
El resultado final de esta actividad de elicitación va a ser el conjunto de requerimientos, el listado de
requerimiento establecido por todas las partes involucradas siendo esto lo que plantea el cliente
específicamente y lo que yo planteo como una mejora, traduzco un problema en alguna necesidad,
etc. En el área del cliente se pueden tener distintos sectores y con todo lo que plantearon se tiene que
hacer el análisis y quedarme con los requerimientos concisos, completos y los que atienden a esa
necesidad real de ese negocio.
Estrategia de elicitación de requerimientos para la actividad de descubrirlos
Estaría conformada por las siguientes tres acciones:
Se deben identificar las fuentes de información donde se obtiene el conocimiento. Una vez que
tenemos las fuentes debemos determinar cuales son las técnicas de elicitación apropiadas o los
métodos de búsqueda o las herramientas necesarias para poder adquirir el conocimiento y poder
descubrir los requerimientos, debe diseñarse la herramienta propiamente dicha para llevar a cabo la
recopilación de información y adquirir ese conocimiento.

Fuentes de información
Va a ser todo aquello que me va a proveer de algo, en este caso, es quien me va a proveer la
información que necesitamos conocer o aquello que contiene la información que necesitamos recopilar
y que de alguna forma voy a obtener los datos de lo que estamos buscando, lo que necesitamos
conocer y las funciones que tiene que realizar.
Cuando tenemos que ir a buscar información, aparecen las personas de existencia física quienes
conforman la organización a la cual le hacemos el sistema, son estas entonces nuestra principal fuente
de información, pero no son las únicas.
Análisis de Sistema Resumen Nicolás Aguirre
Los registros es lo otro importante, denominado como información documentada, todo lo que este
registrado en algún formato me puede estar proveyendo de información que necesito considerar, y
luego también para aquellos negocios o situaciones donde haya otro sistema que esta en
funcionamiento y procesa parte de la información y todo software que maneje información de esa
organización también me va a proveer de la información necesaria. Fuente es algo que contiene, en
este caso es la información necesaria para poder conocer algo y encontrar funciones, conocer como
se ejecuta, encontrar datos y definir distintas acciones y encontrar los requerimientos.
Personas: son la principal fuente de información y a la vez nuestros futuros usuarios, nos van a dar la
problemática, las necesidades, cuándo hablemos de validación nos van a hacer el feedback. Estas
figuras pueden ser futuros usuarios, empleados, nivel ejecutivo y directivo, gerentes, responsables de
área, todos aquellos relacionados con el sistema que me provee algo de información y también clientes
del negocio en los casos donde se deba indagar sobre los mismos para poder establecer el sistema.
Lo mismo ocurre con los proveedores, serán fuentes de información solo en el caso donde los mismos
deban poder acceder al sistema. Las personas son aquellas que contengan información que nos va a
afectar de alguna forma al sistema a desarrollar, en función de eso, pueden ser de uno a muchos los
elementos que conforman las personas.
Información documentada: va a comprender todo aquello que está por escrito en formato papel o
digital, formal o informal, pero toda esta información documentad anos da también otor tipo de datos
que se complementa con lo que las personas nos informen que nos va a dar para ver estructuras de
datos, como se registra la información, que hay estipulado que se debe hacer, que formularios
preexistentes hay, que documentación estadística, que reportes, que salidas generan.
Dentro de la información documentada podemos tener:
• Documentos formularios comprobantes: tienen que ver con los remitos, facturas, presupuestos,
que son documentos formales que de alguna forma tiene o un formato preexistente y se
completa o el sistema lo emite.
• Manuales: hay organización donde tiene manuales donde definen si es de procedimiento que
áreas están afectadas, cual es el objetivo, que documentos maneja, cuales son las funciones
que tiene que realizar, la secuencia de funciones. Si una organización tuviera eso y el sistema
debe comprender algo de ese aspecto, los manuales son materiales de lectura que deben
analizarse y van a dar información.
• Reportes, listados e informes: son generados para toma de decisiones, pueden ser detallados,
resúmenes, estadísticos, gráficos. Todo me va a servir siempre y cuando sea información
relacionada con lo que nosotros queremos descubrir, conocer para plantear requerimientos, no
van a ser todos los reportes que la organización genere.
• Estándares, normativas, leyes, reglamentos internos.
Sistemas y software en funcionamiento: actualmente la mayoría de las organizaciones usan softwares,
tienen otros sistemas de funcionamiento, teniendo que indagarlos en caso de que se relacionen con
nuestros sistemas. Puede ser que debamos desarrollar una nueva función que se debe integrar con
un sistema actual, con sus bases de datos.
Dependiendo de que debamos desarrollar y la necesidad del cliente van a ser nuestras fuentes de
información que vamos a indagar a leer, a profundizar para encontrar esos requerimientos, datos, y
detalles de funciones y las restricciones.
Análisis de Sistema Resumen Nicolás Aguirre
Técnicas de elicitación
Son métodos de búsqueda y/o herramientas que deben utilizarse, para adquirir el conocimiento, son
técnicas para recopilar información.
Todo parte de tener un contacto con el cliente, las primeras actividades es comunicarse con el y tengo
que busca información a través de una serie de técnicas en una serie de fuentes. Estas técnicas son
las siguientes:
Entrevistas porque todo el sistema se construye con el uso de entrevistas trabajando con este futuro
usuario y con todos los clientes. Normalmente las entrevistas son a personas, pero existen otras
técnicas como cuestionarios, análisis de documentación, observación, torbellino de ideas, pero existen
muchas otras más, pero las mencionadas son las más utilizadas.
Entrevista
Es una de las mas utilizadas, siendo una conversación dirigida entre dos o mas personas, pero al
menos dos: un entrevistador y un entrevistado. Siempre tiene un objetivo claro, un propósito especifico,
tiene un formato de preguntas y respuestas, está orientada a realizarla de forma personal, es decir,
siempre interactúan dos personas.
Normalmente siempre fue presencial, yendo al lugar donde esta en el cliente. Si bien siempre fue
personal, si pueden cambiar los medios, por ejemplo, hacer una entrevista con un formato virtual, pero
nunca dejando de ser una interacción entre dos personas.
Cuando hacemos una entrevista queremos percibir opiniones, sentimientos de los entrevistados,
necesidades reales en función de sistemas, aparte de información de los procesos y funciones, que
es lo principal, objetivos de la organización, de un área, que se busca en ese trabajo. También vamos
a capturar los problemas que van teniendo las personas en su trabajo diario y también vamos a captar
cuestiones informales, procedimientos informales, todo aquello que acompaña a la formalidad, a la
ejecución que estaría prevista de realizar una tarea especifica dentro de una empresa.
Para poder encontrar este distinto tipo de información y contexto tendremos que organizarnos,
establecer una serie de pasos, organizar el equipo que va a realizar la serie de preguntas, que es lo
que queremos indagar, que necesitamos preguntar para poder aprovechar la entrevista y la
información recopilada.
Por otro lado, como se establece una relación en ese momento de la entrevista con otra persona,
tendremos que de a poco desarrollar la habilidad para poder crear un clima cómodo de confianza en
el cual la persona entrevistada pueda transmitir, contarnos su situación real y nosotros de toda esa
situación de como se realiza su tarea, que información maneja, mas sus problemas, sus ansiedades,
sus sentimientos poder extraer de allí los requerimientos. Esto va siendo una habilidad que se puede
ir mejorando conforme desarrolla nuevos sistemas pudiendo llevar ese dialogo que establecen esa
interacción que lleva tiempo porque no vamos a estar todos los días hablando, sino en un tiempo
acotado poder obtener la información de la recopilación que me permita detectar los requerimientos.
La idea es organizarnos para que logremos recopilar la información, opiniones, sentimientos, situación
normal de lo que debería ser y a su vez con mayor tiempo debemos poder captar problemas
personales y poderlos quitar de problemas reales del proceso del negocio. De a poco se va indagando
con la persona que tareas realiza, que problemas se le presenta, que necesidades tiene y en conjunto
vamos definiendo, encontrando, esas necesidades o requerimientos.
Análisis de Sistema Resumen Nicolás Aguirre
Actividades para preparar una entrevista
Las tres grandes actividades son: Planeación de la entrevista, la Realización de la entrevista y al final
siempre se hace un Análisis de la información y elaboración de un informe y conclusiones.
Todo esto se hace para obtener los requerimientos.
Planeación
Esta misma actividad se divide en cinco grandes pasos o tareas para poder planear la misma, siendo:
A – Lectura de antecedes
B – Establecer objetivos de la entrevista
C – Selección de los entrevistados
D – Preparación del entrevistado
E- Selección del tipo de preguntas, estructura y documentación
Lectura de antecedentes
Siempre que debamos pensar que vamos a hacer una entrevista nosotros debemos tener alguna
información previa de hacia donde vamos para poder elaborar las preguntas, debemos tener noción
de ese contexto previo. Se deben buscar y luego leer cualquier antecedente de la organización, de
ese negocio, de las funciones, del rol de las personas que vamos a entrevistar. Al conocer ese contexto
y busca información de ese espacio donde vamos a indagar podemos hacer las preguntas de una
forma mas correcta.
Pueden ser: un informe anual reciente, un boletín corporativo, cualquier comunicación que explique al
público las características de la organización o sitios web.
De todas formas, leer un poquito cualquier material que me estén brindando yo estaré conociendo el
vocabulario que maneja esa organización, es bueno asimilar y comprenderlo para cuando se hagan
las preguntas estar manejándome con los mismos términos, comprendiendo lo que significa.
Esto va a permitir aprovechar al máximo las entrevistas, debiéndose optimizar el tiempo puesto que el
tiempo de disponibilidad del cliente es limitado, por tanto, esta lectura nos sirve para poder aprovechar
dicho espacio.
Establecer objetivos de la entrevista
Cada vez que vamos pensando cada entrevista se tendrán que definir los objetivos, que debemos
buscar. ¿El sistema debe ser nuevo? ¿Reemplazar uno existente? Al área que voy: ¿Qué le debo
preguntar? Porque va a estar involucrada o no esa persona: ¿Qué tipo de relación tendrá con el
sistema? Debo tener en claro el objetivo de la entrevista, habiéndome servido los antecedentes para
saber hacia dónde voy, que información me hace falta profundizar, indagar o buscar.
Existen aspectos fundamentales sobre el procesamiento de la información y el proceso de la toma de
decisiones sobre los que se deseara hacer preguntas. Cada vez que se establezcan objetivos de la
entrevista debo tener en cuenta:
Fuentes de información- formatos de la información- frecuencia de la toma de decisiones -la calidad
de la información - el estilo de la toma de decisiones.
Análisis de Sistema Resumen Nicolás Aguirre
Selección de entrevistados
Cuando voy a entrevistar la principal interrogante es a quien entrevistaré, quien contiene la información
que a mi me va a servir. En general, si es una organización y tiene distintos niveles, se deben indagar
cada uno de ellos.
Siempre se parte del nivel superior, directivo, gerencia y de allí para abajo, todo el sistema parte de un
planteo general de alguien que está en el nivel superior y luego deberé encontrar información mas
detallada en los niveles inferiores, a nivel mas operativo.
Vamos a tener varios involucrados, si el sistema necesita alguna parte web para que accedan otros
involucrados a ese sistema como un cliente o un proveedor para gestionar compras o un área de
sistemas externas y deba relacionar de alguna forma deberemos tener un conocimiento de cuantas
personas involucradas en ese futuros sistema deberemos tener en cuenta y de esa forma establecer
distintas entrevistas a cada uno.
En función del nivel de la organización que esa persona ocupa uno establecerá tipos de preguntas
apropiadas para el nivel y la función que lleva a cabo esa persona. A medida que bajamos de nivel
tendremos mas personas en ese rol, por tanto, se aplica el concepto de muestra representativa de una
población. Si de 10 empleados de ventas, yo considero que 4 es una buena muestra, con ellos me
puede ser suficiente para hacer una entrevista.
Se selecciona una muestra porque no se puede preguntar a todas las personas involucradas, a todos
los futuros usuarios de los niveles operativos, hay un costo que significa llevar a cabo la elicitación que
está relacionado con el tiempo y un costo que tiene la misma. La idea es, una vez seleccionados los
entrevistados seleccionar las preguntas apropiadas según el nivel que vamos a tener.
Preparación de la entrevista y del entrevistado
Cada entrevista se tiene que pactar en un tiempo, día y hora especifica. Tengo que coordinar con esa
persona, con tiempo, no puedo hacerlo de un día para otro de forma espontánea, necesitamos mayor
formalidad con las personas que forman parte de ese negocio, además como es en su lugar de trabajo
uno va a consumir horario de trabajo del entrevistado.
Normalmente se dice que una entrevista debería durar de cuarenta minutos a una hora, siempre la
llevamos a una hora y media, aunque la formalidad dice no más de una hora, esto es debido a que
consumimos tiempo en el trabajo de esa persona y porque pasada la primer hora la atención y el
interés del entrevistado se puede llegar a ir.
A veces pueden llegar a tener dependiendo el área de indagación alguna aprobación formal que tiene
que ver con la preparación de la entrevista para ver si alguno necesita una autorización del tiempo si
es un operario un empleado de nivel inferior lo mismo se deba realizar o requerir una autorización
formal para la organización de la entrevista.
Selección del tipo de pregunta, estructura y documentación de la entrevista
La idea es que una vez que yo se el objetivo hacia donde voy, tengo información de los antecedentes
y se cual es el entrevistado, tengo que elaborar cuales son las preguntas apropiadas y correctas para
realizarle al mismo. Viene un espacio de redactar preguntas que cubran los aspectos fundamentales
detectados y que voy a realizar para cumplir con los objetivos de la entrevista.
Todas estas reglas sirven, pero cada vez que uno entrevista a alguien, dependerá todo de la actitud o
personalidad de ese entrevistado y a medida que uno va realizando mas entrevistas va aprendiendo
Análisis de Sistema Resumen Nicolás Aguirre
a manejar mejor la situación y lograr obtener la información necesaria y no mucha información
irrelevante debido a que la persona entrevistada se fue por otro camino o se terminó la hora.
Para terminar de elaborar las preguntas tendremos que
considerar los tipos de preguntas a realizar, darle una
estructura forma u orden en la entrevista y a la vez definir
cómo voy a documentarla.
Por un lado, tenemos los tipos de preguntas en abiertas,
cerradas y exploratorias. Por otro, tendremos que ver
que estructura le daremos a la entrevista pudiendo ser
estructuradas y no estructuradas y dentro de las
estructuradas hay una clasificación que puede ser
pirámide, embudo o diamante. Finalmente se completa
este ultimo paso de la planeación de la entrevista con lo
que establecer como voy a documentar, pudiendo
usarse dos técnicas conocidas como toma de nota o
grabaciones.
Los tipos de preguntas:
• Abiertas: son aquellas preguntas que están formuladas de tal modo que el entrevistado se
puede explayar en su respuesta, el concepto de abierta viene porque deja abierta la posibilidad
de respuesta.
• Cerradas: son aquellas en donde las posibles respuestas de ese entrevistado estarán limitadas,
la pregunta estará formulada de tal modo donde la respuesta es un dato preciso, un número,
un nombre, una función, algo concreto, algo donde las posibles respuestas son limitadas y
concretas. Pueden ser preguntas bipolares, significando que yo formulo la pregunta y las
opciones posibles de respuesta del entrevistado son dos, por eso bipolar, siendo un si/no
verdadero/falso de acuerdo/ en desacuerdo. También puede formularse múltiple opción, donde
se lanza una pregunta y entre las opciones que planteo puede elegir una única respuesta, pero
siempre es una respuesta concreta.
• Exploratorias o de sondeo: son aquellas donde su propósito es indagar algo más allá o abrirme
paso para ampliar cierta problemática o información que estamos buscando. La idea es ir más
allá de la respuesta inicial para obtener un mayor significado y aclara o ampliar puntos del
entrevistado.
Dentro de lo que es una pregunta abierta tiene una serie de características complementarias a su
definición siendo que el entrevistado se puede expresar de forma amplia y completa. Se pueden utilizar
para conocer la experiencia global acerca de un producto. Permite saber lo que piensa la gente sin
necesidad de saber cuantas personas piensan de cierta forma. Las respuestas son fáciles de
interpretar y de tabular. El entrevistado puede responder con sus propias palabras. La primera
pregunta debe despertar el interés del entrevistado. Las preguntas se realizan de forma directa, en
algunos casos no se estimula la respuesta con opciones dentro de la pregunta. A continuación,
ejemplos de preguntas abiertas
Análisis de Sistema Resumen Nicolás Aguirre
Ventajas
y
desventajas
de
la
pregunta
abierta

Dentro de lo que es la pregunta cerrada las posibles opciones de respuestas están limitadas a ciertos
datos concretos. Sus características son las siguientes: son fáciles de clasificar y analizar, solicita
respuesta breves, especificadas y delimitadas. Requiere de un menor esfuerzo por parte de los
encuestados. Limita las respuestas de la muestra. Se utiliza generalmente en investigación
cuantitativa. Son relativamente objetivamente.
A continuación, se presentan unos ejemplos:

Ventajas
y
desventajas
de
la
pregunta
cerrada

Comparación de tipos de pregunta

Tenemos en ambos extremos los tipos de pregunta, y en el medio la característica o atributo de la
pregunta.
En cuanto a la confiabilidad de los datos, una pregunta abierta es baja y una cerrada es alta porque
una cerrada es concreta entonces la respuesta que me dio respondió la pregunta efectuada y la abierta
cuando me cuenta todo tengo que extraer cada dato concreto y de esa misma forma se lee el resto
del cuadro.
Análisis de Sistema Resumen Nicolás Aguirre

Las preguntas exploratorias habíamos dicho que la idea es que intenta ampliar la respuesta del
entrevistado, tienen la forma del por qué ocurre algo o por qué es x cosa.
Indaga ampliando algo y acompaña a otra pregunta, por lo general abierta. Ejemplos:
La pregunta abierta sería como le
entregan el informe y después cuando
me va contando yo detecto un
problema, realizando entonces una
ampliación de la respuesta asociada a
una pregunta anterior que puede ser
abierta o cerrada, generalmente abierta
y se complementan.

Hay un par de consideraciones que son errores que hay que evitar en la pregunta, como las preguntas
tendenciosas, o las preguntas dobles.
Las tendenciosas son aquellas que están elaboradas de forma tal que la pregunta lo esta llevando a
una respuesta que me gustaría tener, se tienen que evitar, siempre que tengo que hacer una pregunta,
generalmente abiertas, tienen que ser preguntas objetivas
Las preguntas dobles: a veces pasa que elaboramos una pregunta y en la misma pregunta
preguntamos dos cosas, generando que la respuesta este orientada hacia una parte de lo que se está
preguntando y no responda la otra parte. Cada pregunta debe enfocarse en una sola temática,
concepto, que quiere abordarse.
Estructura de la entrevista
Las entrevistas pueden ser estructuradas o no estructuradas, y a la vez dentro de la estructurada
puede ser piramidal, de embudo o diamante.
Análisis de Sistema Resumen Nicolás Aguirre
En la estructurada, como su nombre indica, es cuando todas las preguntas están planteadas de
antemano, con una secuencia lógica y se siguen durante la entrevista como respetando esto de una
manera estricta. Me voy guiando con el orden de preguntas, no me salgo de esa línea y realizo las
preguntas pensadas previamente siguiendo la estructurada definida.
En la no estructurada no quiere decir que es desorganizada y no sabemos para que vamos, si no que
se refiere a que las preguntas se mas o menos las temáticas que voy a abordar, pero no tengo una
lista elaborada de preguntas para seguir en forma exacta. Carece de estructura formal, no están
alineadas de forma exacta para seguir estrictamente, pero no significa que falte la preparación.
Dentro de la estructuradas tenemos la que se denomina piramidal establece una serie de preguntas
generales en la base y una serie de preguntas específicas en la punta. El entrevistador arranca con
preguntas concretas del tipo cerradas y luego durante la entrevista va estableciendo una serie de
preguntas que están orientadas a desarrollo o respuestas mas generales, por eso hace uso de
preguntas abiertas y el sondeo que puede acompañar al final. Conviene utilizar cuando el entrevistado
necesita una introducción hacia el tópico principal, o el entrevistado se niega a involucrarse en el tópico
o se necesita encadenar preguntas para llegar a una conclusión.
La estructura de embudo seria a la inversa de la piramidal, empiezo la entrevista con preguntas
abiertas que pueden hacerlo cómodo para entrar en tema y voy cerrando la entrevista y lo voy llevando
a preguntas cerradas para obtener información concreta que necesito recopilar, facilita el inicio de la
entrevista porque el entrevistado se pone cómodo cuando empezamos con preguntas donde se puede
explayar. Conviene utilizar para facilitar el inicio de la entrevistado, si el entrevistado esta
comprometido con el tópico y necesita cierta libertad para expresar sus emociones o para organizar la
entrevista de modo de poder obtener información detallada sin largas secuencias de preguntas
La estructura diamante combina las anteriores, empezando con preguntas especificas durante el
centro de la entrevista vamos haciendo preguntas abiertas y de sondeo y vamos terminando con
preguntas especificas y cerramos la entrevista. Este tipo de estructura requiere mas tiempo en la
preparación de la misma y también en su desarrollo, pero eso una de las mejores utilizadas para
mantener el interés del entrevistado.
Análisis de Sistema Resumen Nicolás Aguirre
Documentación de la entrevista
Las dos posibles formas de documentar una entrevista pueden ser o la grabación o la toma de notas.
La grabación en lo que es una entrevista puede ser audio o una grabación con imagen mas audio, lo
importante es que siempre que hagamos una entrevista debemos registrar los aspectos importantes,
debido a que en el tiempo se le empieza a olvidar algunos detalles, o confundir los conceptos. Al
registrarse la información nos da la garantía de tener toda la información recopilada.
Por un lado, podemos hacer una grabación que requiere siempre una autorización, informar el destino
de la grabación y también asegurar confidencialidad. De acuerdo con cada tipo de negocio deberemos
indagar o desarrollar sistemas con manejo de información más confidencial, por tanto, debe
asegurarse la privacidad de esta. Al estar grabado podemos estar distribuyendo esa grabación por
cualquier lado, por eso, debemos ser prudentes y manejarnos con cierta ética.
La otra forma es una toma de notas, la información que me va brindando la registro en algún lado.

Ventajas
y
desventajas
de
la
grabación

Ventajas
y
desventajas
de
la
toma
de
notas
Análisis de Sistema Resumen Nicolás Aguirre
Niveles de la organización en una entrevista

A nivel superior toda la información que se puede indagar es de gestión, objetivos generales, aspectos
globales de la organización, objetivos, de funciones en general, de proyecciones. A medida que
bajamos de nivel en cuanto a estructura organizativa se deben ampliar el nivel de detalles de las
preguntas, no le puedo preguntar a un gerente general que datos concretos registra para una venta,
pero si que toma de decisiones, estadísticas y resúmenes necesita para ella. En los niveles operativo
si se pueden preguntar en detalle cada función, tarea, dato y que consuma la persona cuando haga
esa función para hacer ese reporte al nivel superior.
Realización de la entrevista
Cuando vamos a realizar concretamente la entrevista es importante la puntualidad puesto que estamos
en el horario de trabajo de otra persona y además hace mucho a la imagen y al concepto que tomen
de la persona y equipo de sistemas. Cuando uno empieza la entrevista hay que recordarle para que
estamos ahí al entrevistado, que estamos buscando, luego comunicar el modo de registro si es con
grabación o toma de notas, siempre dando garantías de confidencialidad de lo que se va a charlar en
la entrevista. Hay que comenzar el desarrollo de la entrevista según lo planeado, es importante
manejar el tiempo porque si yo acorde una duración de una hora u hora y media, si yo tengo 10
preguntas a realizar y paso media hora y vamos por la segunda pregunta significa que se nos esta
yendo el tiempo de la entrevista, por ende, hay que tener un buen criterio de manejo de tiempo y tener
la habilidad que no se nos vaya la hora de la entrevista, ya que la misma no puede expandirse más de
lo acordado. Siempre cuando termina la entrevista, hay que informar al entrevistado sobre los pasos
posteriores a la entrevista.
Análisis de Sistema Resumen Nicolás Aguirre
Análisis de la información relevada y elaboración de informe para obtener los requerimientos
Siempre que hacemos la entrevista, al finalizarla, debemos analizar la información recopilada. De esta
vamos a obtener un resumen con la información recopilada. Cuando uno va charlando va tomando
nota de lo que están hablando, pero no va armando los requerimientos ahí nomás, uno luego de que
termina la entrevista hace ese análisis, mas las otras entrevistas que se hayan dado más otras técnicas
uno va elaborando un resultando donde se obtienen requerimientos, o se completan otros si ya se
tenían requerimientos de forma previa, etc.
Si es importante cuando uno termina la entrevista revisar la toma de notas o grabación viendo si algo
de lo que está ahí me da conclusiones concretas, puesto que si yo hice la entrevista y alguna cuestión
me quedo en duda me puede dar pautas para indagar a futuros algo que me quedo inconcluso, o
confirmar requerimientos que ya tengo o completar listado, de alguna forma hay que revisar
información recopilada.
Resultado de la entrevista
La idea es descubrir requerimientos, la elicitación dentro del proceso de ingeniería de requerimientos
es este descubrir requerimientos y de alguna forma adquirir conocimiento de ese dominio, negocio u
organización. A medida que yo voy obteniendo los requerimientos voy a ver que, si seguimos con las
actividades de elicitación, los voy a clasificar en funcionales y no funcionales y los iré priorizando para
saber con cual trabajaré primero dándole un orden al tratamiento para el desarrollo del sistema.
A parte de priorizarlo y de obtener un orden me va a dar nuevas preguntas, situaciones donde deba
indagar o ampliar para poder seguir continuando con esos requerimientos. Supongamos que como
primer requerimiento es registrar datos del cliente y los pedidos y como requerimiento no funcional el
cliente quiere un sistema web, cuando empiezo a analizar con un poco más de profundidad, ¿Cómo
se procede al registro de un pedido? ¿Qué datos se registran? ¿Qué formas de pago existen? Si la
entrevista fue con alguien de gerencia general nos habrá dado un panorama general, por tanto,
deberemos ir con un empleado de venta para poder resolver esas inquietudes que se despertaron a
la hora de desarrollar el sistema, de esta manera completando la lista de requerimientos, modificando
otros y pudiendo lograr este desarrollo del sistema propiamente dicho con las reiteradas entrevistas
en los distintos niveles de la organización.
Hay que recordar que este trabajo de elicitación va a generar conocimientos que van a ser de entrada
para la siguiente actividad o proceso en la ingeniería de requerimientos que es la especificación donde
se van a tomar los requerimientos y se trabajara en el detalle de la propuesta.
Técnica de elicitación: Observación
La observación es una técnica en si misma que por si sola no sirve para hacer todo el trabajo de
elicitación, pero si se complementa con las otras siempre y cuando se de este contexto de lo presencial
donde se puede observar.
La observación es este reconocimiento visual de un contexto o una situación real, voy a poder ir viendo
como una tarea se lleva a cabo, como realizan las actividades, como es atendida las diferentes
personas , si es la cuestión de un cliente, como se efectúan si es una tarea de producción como la
realiza el operario, voy a observar como se hacen los pasos para ejecutar una tarea o para espacios
de ambiente donde están tomando decisiones y ver qué tipo de información que usan, forma de dialogo
y distintas cuestiones que tienen que ver con esos espacios reales.
Análisis de Sistema Resumen Nicolás Aguirre
A través de la observación realizamos el reconocimiento visual y la indagación y exploración de las
actividades de la organización de como realizan su trabajo las personas, de la forma en que se toman
las decisiones y del contexto físico en donde realizan su actividad, el profesional de sistemas puede
profundizar en lo que se hace y no solo lo que se dice o se tiene documentado.
La idea es que al observar vamos a tratar de focalizar el cómo desarrollan sus actividades en ese
espacio real, el cómo se establecen las relaciones entre las personas y con su trabajo, en los mensajes
como hablan, vocabulario usado, si son formales o informales, como es el ámbito del trabajo.
Nosotros podemos obtener información de los tomadores de decisiones en un ambiente en donde
pueda participar de una reunión de una junta o en el accionar del gerente se junta con algún jefe y
como analizan la información para tomar decisión y en función de eso podemos observar como se
desarrolla la tarea. También se puede observar los empleados que trabajan en la organización como
hacen su tarea y como es el ambiente de cada uno de ellos en ese contexto donde llevan a cabo la
tarea.
Por eso la observación es complementaria, ya que cuando voy a la entrevista, la persona me cuenta
como hace su tarea y con la observación veo y confirmo o puedo modificar algo de lo que ellos me
contaron, una cosa es que me cuenten como lo hacen y otra es que vea como es y certifique esa
acción que está haciendo. No hay interacción con otras personas, el observar suele ser una de las
primeras técnicas para empezar la indagación de información.
La observación para que sea útil debe estar estructurada, previsto lo que voy a observar y no que
caigo un día quince minutos a mirar que están haciendo, la idea es que tenga un orden, un por qué de
lo que quiero buscar y definir que voy a observar concretamente, los sujetos de la observación y
establecer cuando voy a ir de forma concreta, donde será (pueden ser diferentes áreas, reuniones y
demás) y un objetivo del por qué voy a observar, no ir para chusmear lo que están haciendo.
La ventaja es que se puede observar actividades
de toma de decisiones de un gerente, el lenguaje
corporal del tomador de decisiones, tareas
operativas de los empleados y el contexto y
ambiente físico en donde se desarrollan las
actividades.
Cuando haya que registrar las observaciones o
las conclusiones ya sea en el momento o a
posteriori sirve establecer que cosas yo quería
observar y obtener un resultado de esa
observación. Nos podemos valer de una
clasificación de posibles adjetivos de lo que
hemos observado. A veces si les permite el lugar
se puede sacar fotos.
Análisis de Sistema Resumen Nicolás Aguirre
Técnica de elicitación: Cuestionarios
Se pueden encontrar como encuestas, es una técnica que consiste en un formato de preguntas y
respuestas, pero la diferencia con la entrevista es que las respuestas y preguntas están dadas por
escritos, no tenemos el contacto personal para hacer las preguntas, están previamente definidas, se
formulan en un escrito y la persona que esta siendo encuestada también la va a realizar por escritor.
Con un cuestionario vamos a poder conocer y estudiar a mas profundidad la tarea que realizan las
personas y captar problemas, de sentimientos, de actitudes en función de la respuesta que me vaya
brindando la persona encuestada. Puede servir como un suplemento bastante útil de las entrevistas.
Cuando nosotros desarrollamos un sistema, solo con el uso del cuestionario no tendríamos toda la
información. Se suplementa con la entrevista.
La información buscada a partir de cuestionarios además de la tarea realizada que es lo que queremos
profundizar también vamos a poder tener información sobre distintas actitudes, sobre opiniones de
algún concepto, una serie de problemáticas que se les presente a las personas, además de
información concreta sobre eso, datos concretos e información y una serie de características que
hagan a la definición del espacio o contexto donde estamos buscando la información.
Uso de cuestionarios
Por un lado, son excelentes para conseguir respuestas que son mas bien especificas y cerradas,
obteniendo respuestas concretas brindando bastante información que puede cuantificarse mediante
análisis rápido, sacando porcentajes y demás. Cuando voy haciendo el cuestionario el uso también de
otra pregunta puedo llegar a descubrir una situación que generen nuevas preguntas clave o a partir de
una entrevista se puede plantear una nueva pregunta que en el cuestionario puedo profundizar y
realizar, además de que puede distribuirse a una audiencia más amplia. Desarrollar estos
cuestionarios y planearlos requiere mucho tiempo.
Actividades para hacer un cuestionario
Son tres grandes actividades: planeación del cuestionario, realización del cuestionario, análisis de la
información recopilada obteniendo conclusiones.
Planeación de cuestionarios
Esta actividad se subdivide en una serie de pasos, siendo ellos:
A – Definir el objetivo y conveniencia de aplicación
B – Elaborar las preguntas y diseñar el cuestionarios
C – Seleccionar las personas que lo realizaran
Definiir el objetivo y conveniencia de aplicación
Siempre que vamos a planear un cuestionario lo primerio que debemos tener en claro es el objetivo,
para que lo estamos haciendo y que buscamos obtener información con ese cuestionario. Se debe
definir que se busca con un cuestionario.
Dentro de la misma actividad debe analizarse la conveniencia de aplicación, el cuestionario tiene
costos y tiempos asociados, por tanto, la técnica de elicitación que se usara en el tiempo que tenemos
y con los recursos disponibles y con el costo que insume tiene que ser bien evaluada para no consumir
Análisis de Sistema Resumen Nicolás Aguirre
tiempo de mas o superar los costos previstos para el trabajo de elicitación. Hay que considerar cuando
conviene usar un cuestionario. Los siguientes son casos para usar cuestionarios:
Si nosotros tenemos que indagar un conjunto de personas, empleados, futuros clientes, que no se
encuentran físicamente en un lugar. AL estar dispersos geográficamente es conveniente el uso de
cuestionario porque sino el traslado para hacer entrevistas para todas las personas consumiría tiempo
y costo de traslado y demás. Cuando están dispersas es un buen indiciador para usar cuestionarios.
Cuando la cantidad de personas que queremos es indagar es mucha, debido a que hay demasiadas
personas involucradas en el proyecto en el nivel operativo es conveniente hacer un cuestionario de
sondeo o búsqueda de información general por cantidad de empleados.
Para llevar a cabo un estudio exploratorio y medir la opinión general y para realizar un sondeo de los
problemas actuales a fin de identificarlos y luego darles seguimientos mediante entrevistas. Lo que es
exploratorio es, por ejemplo, cuando quiero abrir una nueva sucursal, la instalación de un nuevo
sistema, que opinión hay sobre una temática y por oro lado sondear el problema es cuando necesito
encontrar toda la problemática en un área operativa que van ocurriendo para poder direccionar el
sistema considerando esa problemática. En estos vasos es conveniente el uso de cuestionarios
Elaborar preguntas
Cuando decidimos elaborar las preguntas hay que recordar que, como va a estar por escrito, hay que
pensar bien las preguntas para que no genere ninguna duda en el momento en que se vayan a
contestar las mismas. Las preguntas de un cuestionario deben ser transparentes, claras, la intención
de lo que se quiere preguntar tiene que ser clara para que la respuesta de la persona pueda ser
realizada y nosotros obtengamos información buscada.
El flujo del cuestionario debe ser convincente, deberán tener un orden lógico las preguntas, para que,
si la persona esta interesada en el cuestionario porque esta bien armado podemos obtener buenas
respuestas, pero si la persona esta enojada con el cuestionario dada su falta de orden lógico no logra
dar una respuesta que estemos buscando.
Los cuestionarios deben poder anticiparse a las respuestas de las preguntas, debemos pensar desde
el otro lado, como seria la respuesta que estamos buscando así sabemos si tenemos que cambiar o
no la pregunta.
El diseño del cuestionario debe ser planificado con todo detalle, porque una vez hecho y enviado para
que lo respondan no hay espacio para correcciones o aclaraciones y lo que respondan va a ser
información que vamos a obtener.
Los tipos de preguntas a utilizar en un cuestionario son los mismos tipos de preguntas que ya se
habían visto antes para la entrevista, siendo abiertas, cerradas o exploratorias añadiendo dentro de
las cerradas el concepto de uso de escalas y como armar las posibles respuestas.
Las preguntas abiertas pueden ser útiles cuando: se debe analizar la respuesta que se busca obtener
para que el resultado sea útil pensando bien la pregunta para que este bien formulada anticipando su
respuesta. Debe tener la precisión necesaria para que pueda orientarse la respuesta a lo que
queremos indagar. Si es de opinión debe ser adecuada la pregunta, porque como queda por escrito la
persona se va a limitar al dar su opinión, pero las preguntas abiertas son idóneas cuando se pide una
opinión. Con las preguntas cerradas uno tiene que dar posibles respuestas de selección, pero cuando
es imposible enumerar todas las opciones también es útil el uso de preguntas abiertas para que
Análisis de Sistema Resumen Nicolás Aguirre
pongan allí las distintas posibilidades la persona que va respondiendo. Las preguntas abiertas son
útiles para los sondeos de opinión y la búsqueda de problemas, útiles para explorar situaciones.
Dentro de las preguntas cerradas, pueden ser útiles cuando: cuando el analista sea capaz de enumerar
todas las respuestas posibles, ya que una pregunta cerrada ofrece todas las respuestas posibles en
el cuestionario, si hay una pregunta y la persona que va a respondernos encuentra la respuesta que
quiere dar, entonces ese cuestionario esta incompleto. Se trata de que esa pregunta cerrada, si es
posible, las opciones selección sean mutuamente excluyentes pudiéndose elegir solo una, pero
dependerá siempre de la información que se esté buscando. Las preguntas cerradas también son
útiles para la exploración en una gran cantidad de personas, ya que una pregunta cerrada es más fácil
de distribuir y analizar luego la información obtenida.

Otro aspecto a considerar es el lenguaje del cuestionario, debiendo ser las preguntas técnicamente
precisas utilizado el lenguaje de ese negocio, de ese lugar, del cliente, de lo que ellos utilizan en su
trabajo diario, evitando la parcialidad debiendo orientar a una respuesta, pero no debe inducirse a que
nos den una determinada respuesta. Debemos dirigir las preguntas a las personas indiciadas, que
sean capaces de responder, correspondiéndose con el área y nivel donde trabaja esa persona. Se
deben utilizar preguntas cortas. Hay un poco de formalidad en los cuestionarios por eso no es útil el
uso de un lenguaje corriente, sin caer en el exceso de confianza.
Uso de escalas
Este concepto amplía a las preguntas cerradas. Escalar es el proceso donde nosotros vamos a asignar
a las posibles opciones de respuesta un número, símbolo, característica para luego medirlo, por eso
el uso de escala se aplica solamente a preguntas cerradas, trabajando con las posibles opciones de
respuestas de alguna forma enumerándolas, clasificándolas o proveyendo algunos símbolos para su
selección y su indicación en la respuesta.
La razón para usarla es para medir los distintos aspectos que estamos indagando, sacando
porcentajes y demás medidas estadísticas. Al usar escalas me encuentro con un elemento de juicio
sobre los temas del cuestionario.
Hay cuatro tipos de escalas:
Nominal: nos sirve para clasificar objetos, posibles respuestas, al enumerarlas, pudiendo incluir
preguntas de si o no.
Análisis de Sistema Resumen Nicolás Aguirre
Ordinal: les agrega un orden a esas posibles respuestas, según algún concepto.
De intervalo: voy a tener distintas posibles respuestas, pero voy a usar valores numéricos, poniendo
un valor que va a tener un intervalo entre uno y otro igual y en esa categoría de numero puedo obtener
una respuesta de lo que estoy buscando.
Proporcional: se combina con la de intervalo, pero en las posibles opciones que yo ofrezco y los rangos
de valores, partimos de un valor inicial de cero.
A continuación, se muestran ejemplos de cada una:

Es recomendable usar cantidad de opción

par para que no se quede en un punto
medio y de esa forma se la juegue por una
opción

Es conveniente cuando hay

muchas opciones
Análisis de Sistema Resumen Nicolás Aguirre

Una vez que nosotros vamos elaborando esas preguntas debemos tener una serie de parámetros de
cómo hacemos útil y como están hechas y el uso de esas escalas. Hay dos principales. Una es de
validez que es el grado con el que determina lo que el analista quiere medir y la otra es la confiabilidad
con la que esta elaborada la misma en relación con la consistencia, orientado a cada vez que tengamos
preguntas realizadas que las respuestas que obtengamos cuando debamos evaluarlas se puedan
medir, cuantificar y sean coherentes no pudiéndose obtener respuestas que se contraponen o nos dan
inconsistencia fruto de haber indagado cosas que no las tenía muy claras y las mezclé en el
cuestionario.
Cuando usemos escalas vamos a tener respuestas más útiles siempre y cuando estén consideradas
todas las posibles opciones y otras las características vistas recién para que sean validas y confiables.
Diseño de cuestionarios
Una vez que sepamos que preguntas queremos usar, organizamos cual es abierta, cual cerrada y de
las cerradas posibles opciones y alguna de sondeo, debemos diseñar, armar el cuestionario y
formularlo. Cuando lo armemos le debemos dar un orden lógico de como las voy a ir presentando a
las preguntas y que secuencias deben tener para ir guiando en el desarrollo de este al encuestado.
Un cuestionario bien diseñado debería tener unas primeras preguntas en donde la persona que va a
ir respondiendo se sienta cómoda y sepa que eso que va a responder lo haga con total seguridad de
que vamos a tener la confidencialidad de lo que va respondiendo y que se sienta en un espacio libre
de ir respondiendo, eliminando su resistencia. Todo va quedando por escrito, la persona debe sentirse
cómoda al brindar su respuesta para que a nosotros nos sirva.
En un caso de un cuestionario vía web no cambian las reglas para la creación de estos cuestionarios.
En cuanto al estilo, tenemos que dejar suficiente espacio en blanco (los márgenes) ya que si esta muy
cargada la pregunta con todo aglomerado le impacta de forma negativa al encuestado. También se
debe ofrecer un espacio adecuado para las respuestas, sobre todo, las abiertas para evitar problemas
de espacio a la hora de responder. También debe facilitase a los encuestados que marquen con
claridad las respuestas, con una cruz, un círculo, tachar la correcta o incorrecta, debe estar claro como
debe marcarse la respuesta adecuada y debe ser consistente, no pudiendo cambiarse la forma de
marcar en diferentes preguntas.
Análisis de Sistema Resumen Nicolás Aguirre
Una vez completado ese análisis debe establecerse el orden para las preguntas de la siguiente
manera:
Las preguntas de importancia deben estar más bien al comienzo, porque a medida que avanza en el
cuestionario las personas terminan cansadas por eso al último deben ir preguntas que no deban pensar
tanto, sino que al comienzo deben ir las que generen internes y la que necesitemos más para obtener
información.
Deben agruparse preguntas del mismo tema.
Debe colocarse la categoría promedio corrida del centro, si se trabaja con opciones pares en vez de
impares para que las personas no vayan siempre al medio.
Seleccionar las personas que responderán el cuestionario
Cuando pensamos los objetivos o el objetivo del cuestionario y llegamos a este punto deberá hacerse
una muestra en base a la información que se quiere obtener y en función de la cantidad de personas
a indagar, no debiendo indagar a todo porque a mayor cantidad de personas mayor cantidad de tiempo
de procesamiento de las respuestas y de costos asociado al tiempo que demande el consumo mayor
para el análisis de la información.
Deben seleccionarse un conjunto representativo de las personas que recibirán el cuestionario,
teniendo que considerar las siguientes variables:
• Antigüedad en la empresa, ya que alguien que entro hace poco no conviene indagar mucho
porque mientras tenga mas experiencias va a poder dar problemas, información de lo que
maneja y mas dominio de lo que hace.
• Responsabilidad en el cargo: los que están en niveles superiores se usan entrevistas, nunca
mandar cuestionarios.
• Otro interés especia sobre el sistema actual o propuesto.
• Empleados que usaran el sistema.
Realización del cuestionario
Para realizar el cuestionario, siempre la dinámica de este es que vamos que tener que entregar el
cuestionario para que sea respondido, teniendo que cambiar la modalidad en la que va a ser
entregado, la modalidad en como va a ser respondido. La realización es entregar el cuestionario para
que se realicen las respuestas concretamente.
Para realizar el cuestionario, cuando se pueda presencial, las posibilidades dentro de lo presencial es
ir al área donde tenemos habilitado hacer la encuesta, ir en un espacio, en un momento citamos a las
personas que están allí, entregamos el cuestionario, esperamos un rato y luego lo recogemos.
Alguna otra posibilidad dentro de lo presencial es que yo establezco que hay un día donde pueda
responder el cuestionario, eso puede ser porque hay distintas personas en distintos turnos, entonces
voy a un lugar, dejo ahí los cuestionarios, dejo en el espacio algún lugar donde me dejen los
cuestionarios con sus respuestas y luego los iré a retirar.
Podemos hacer uso independientemente de la que personas estén en ese espacio o no, hacer uso de
alguna plataforma o herramienta de formato digital, independientemente que las personas
encuestadas estén dispersas o no siendo obligatorio cuando las mismas si se encuentren dispersas.
La idea es garantizar un formato donde las preguntas del cuestionario no vayan a cambiar.
Análisis de Sistema Resumen Nicolás Aguirre
Análisis de información recopilada obteniendo conclusiones
Hay una serie de aspectos como para tener en cuenta.
En función de las respuestas que voy leyendo me abren posibilidades en una futura entrevista o un
nuevo cuestionario de información o aspectos que necesite profundizar. Alguna respuesta me puede
disparar un nuevo camino, una nueva alternativa a esa información.
Por otro lado, voy a poder medir las respuestas y obtener cuantificación de la información a partir de
las respuestas obtenidas y me va a permitir establecer algunos requerimientos y toda esa información.
Todo va en búsqueda de obtener los requerimientos, refinar algunos, mejorar los que encontré, detallar
otros.
Técnica de elicitación: análisis de documentación
El análisis de documentación es otra de las técnicas también relevantes que nos va a brindar como
otro conjunto de datos o información, que, asociados o combinados con buenas entrevistas o algunas
de las otras técnicas nos va completando toda la información necesaria que necesitamos recopilar
para poder detectar datos, estructuras de datos, relaciones, ver que documentos, formularios. Nos va
a brindar una cantidad de detalle que, en una entrevista, en un cuestionario, obtenemos una visión
una información de su accionar, espero análisis de documentación es todo lo que está escrito que lo
podemos analizar y todos los sistemas que podemos indagar nos va a completar la otra pata de la
información completa de lo que podemos ver.
El análisis de documentación es esta acción que vamos a realizar para poder descubrir y analizar
todos esos datos de lo que se registra, el formato que tiene, cuanta información se omite de lo que
debería ir en un formulario. De las salidas que son reportes e informes como esta escrita la
documentación, de que tipos de datos hacen porcentajes, de que hacen gráficos estadísticos y como
registran cada uno de todos los datos, es bastante nutritivito todo lo que podemos obtener de este tipo
de técnicas y de todo lo que este por escrito o de alguna forma documentada en alguna organización
y siempre como complemento a una entrevista también. Esta técnica por si mismo no puede ser usada
y esperar encontrar todos los requerimientos, siempre complementa a torbellino de idas o entrevistas
según el caso que se investigue.
Nos va a permitir comprender todo de la importancia y el uso de todo lo que este en papel o
documentado que de alguna forma exista por escrito, formalizado o no, de lo que maneja una
organización. También puede conocerse como investigación de antecedentes, siendo esta otra
denominación para la misma técnica.
En el análisis se trabaja sobre la fuente de información documentada y sobre otros sistemas que están
funcionando.
El tipo de información buscada van a ser hechos y cifras. Por ejemplo, si estamos indagando un reporte
de ventas vamos a ver que las columnas que usa ese reporte de ventas vamos a ver las columnas
que usa, que datos totalizan, cual es la información que le sirve, que datos o cantidades hay de los
productos, si hablan de ventas mensuales, si clasifican por vendedor, etc.… Uno va investigando
hechos y cifras, detalles de esos datos, el formato de esa información. Hay una cantidad de detalles
que en una entrevista no pregunta pero que nos sirve al momento de analizar esto por escrito y que
de los datos yo obtengo la información completa de ese contexto organizacional.
Análisis de Sistema Resumen Nicolás Aguirre
Todo esto me sirve para que en función de indagar esos datos o como los registran me sirven para a
parte de encontrar requerimientos, para saber que funciones y que datos manejar, a futuro para
construir un diagrama de clases y saber si hablamos de datos de un cliente que se registra de esa
persona, si son empresas, a mi me sirve mucho de la definición de detalle de los datos de todo lo que
voy observando.
Em general se clasifica en análisis de documentos cuantitativos y cualitativos, pero en la practica no
hay una discriminación si es de un tipo u otro, pero el conjunto me sirve para analizar los datos escritos.
Análisis de documentos cuantitativos
Nos referimos a aquellos que tienen esta forma de reportes o de informes que se generan para toma
de decisiones, de desempeño, de distintos conceptos que generen informes, de todo lo que este en
estándares, normativas, leyes, reglamentaciones, en todo los registros de transacciones que tenga
ese negocio como documento, formularios, comprobantes varios dependiendo al tarea que lleva a
cabo ese negocio, y también el análisis de sistemas existentes es cuantitativa porque la información
esta concretamente escrita y yo puedo analizar y encontrar datos, formato de datos, rangos posibles
de valores y demás y cuando analizo sistemas existentes mucho de lo que esta ahí funcionando tengo
un menú de opciones, una pantalla, los datos están ordenados, tengo una base de datos porque ese
sistema funciona con alguna información persistente en algún lado. Todo eso me va a servir para
definir que debe hacer el sistema que me toque analizar, completar requerimientos en función de las
funciones que deba reemplazar si es un sistema existente o las funciones que deba realizar
considerando estas otras fuentes que son todo aquello que este por escrito.
Las actividades que se hacen en estos análisis de documentos cuantitativos son:
Tenemos que recolectar ejemplares de todas las formas, refiriéndonos a documentos, formularios,
comprobantes, no pudiendo hacer todo el universo posible, sino que se toman modelos. Si hay un
presupuesto, hay una factura y un remito, al menos un modelo pero que este en formato general y tal
vez dos o tres si yo quiero ver si los registros de información manual de distintas personas como
generan distintos presupuestos si no tienen un formato establecido, pero sino, con un modelo o
ejemplo puede servir para cada tipo de documento.
Vamos a observar la forma que tiene, como se agrupan los datos, el tipo de detalles, fecha y hora, nos
sirve para poder encontrar patrones de como van registrando, por donde pasa el documento, quien
interviene en un documento, quien lo escribe y demás.
Nos va a servir revisar como se va llenando los mismos, si todas las personas tienen como tipificada
la información que registran, porque nos ira dando valores predeterminados para futuros diagramas
de clases, cuantos atributos voy a tener, que información debo ordenar. Un sistema que voy a proponer
va a mejorar la forma en como manejan todo. Si hay información que se hagan como reportes a través
de gráficos, saber que gráficos debe generar mi nuevo sistema, que información es necesaria registrar
para que luego pueda sacar esa información resultante y con los distintos documentos voy viendo
como nominan sus productos para que yo sepa después que determinación hacer de atributos que
conformen cada uno de los conceptos y las clases que deba encontrar.
De alguna forma todo me sirve para la definición de la propuesta para encontrar requerimientos y a la
vez ver algunos problemas como cuando el documento se omite, cuando no esta bien realizado, si
siempre se genera en forma correcta o no, etc.
Análisis de Sistema Resumen Nicolás Aguirre
Otros signos para observar en el análisis de documentación son los datos o la información que no
fluyen como se pretende, voy encontrando problemáticas, detalles de cosas que debo analizar o falta
de compresión por parte de los empleados acerca de que tal vez tienen en claro sus tareas, pero no
saben desde donde viene algo y como continua entonces voy encontrando este tipo de cosas. También
me puedo encontrar con duplicación innecesaria de trabajo, redundancia en algunas tareas o algunos
registros a veces también cuellos de botellas debido a que a todo confluye en una persona generando
retardos en el resto de las tareas y demás.
Esto me sirve para que cuando haga mi sistema, encuentre requerimientos que eliminen o reduzcan
estos problemas mencionados.
Análisis de documentos cualitativos
Hay mucha otra información que tal vez no tiene la formalidad de una factura, pero también es
información de como ese contexto ese negocio lo maneja, me va a servir, como tablero de noticias o
transparentes, en el caso de una empresa que trabaje presencial completamente. Uno puede observar
el tipo de información que se maneja en una publicación que usan en áreas de trabajo, los sitios webs
también nos sirve porque ahí podemos ver la misión de la organización, lectura de antecedentes y
demás que podemos usar en entrevistas. Los manuales nos pueden servir porque me dan mucha
información de quien hace una tarea, cual es el procedimiento establecido y también la forma en que
se comunican y si se manejan por memorándums y todo el registro de información que influye en la
parte interna de una organización.
Vamos a tratar de buscar el lenguaje con el que se comunican, como son los mensajes dentro de la
organización, las cosas que se manejan bien y cuales se ven desordenadas, o que partes del manual
se hacen y no se hacen.
Torbellino de ideas o Tormenta de ideas (Brainstorming)
Se utiliza para cualquier contenxto y su concepto como lo dice su ombre es un trabajo en algun
momento para poder generar ideas sobre algun concepto, siendo en nuestro caso, que puede llegar a
cubrir o desarrollar el sistema que vamos a realizar, que están queriendo los clientes que se realice.
La técnica permite que el grupo de personas que participan en esta reunión puedan sugerir, explorar
ideas en un espacio donde, no importa si puede ser muy descabellada es un juego de poder tirar todas
las ideas que se me ocurren, poderlo charlar y luego ver de todo eso posible cual concretamente nos
delimita, nos delinea a donde ir. Se trabaj en una sesión de mínimo 4,5 perosnas y máximo 8,10. Emtre
los integrantes de ese grupo tienen que haber según el tema tratado distintos involucrados que
atiendan a la situación, en el caso de sistema, algunos profesionales de tipo de sistema y algunos del
lado del equipo de negocio del cliente. No se puede hacerlo sin una de estas partes porque para eso
nos va a aportar algo en lo que es el desarrollo de un sistema esta técnica.
Realización de actividades
Se realiza en dos fases, la idea es un día y horario previamente organizado, se define a uno d ellos
participantes como líder o moderador que va a guiar la reunión de ese día, constando de dos fases,
una primera donde se generan ideas y otra de compresión de cuales de esa ideas se pueden llegar a
trabajar
Análisis de Sistema Resumen Nicolás Aguirre
Fase de generación
Se van a comentar, o se dará espacio para que los participantes ofrezcan todas las ideas posibles, es
como, tirar todas las ideas que se nos ocurren.
Cuando inicia la sesión la idea es que se tiren ideas sobre un tópico, todas las que se les puedan
ocurrir para poder considerar. Llegado el momento hay que darle un cierre, porque uno podría estar
todo el día tirando ideas pero no concretando nada, por eso, el líder que dirige la reunión cuando no
se generan mas ideas o cuando se dijeron muchas ideas o cuando tiraron tantas y ya no es necesario
seguir aportando nuevas, el líder define que hasta ahí termina la fase generación. En ese momento se
escribirán las ideas que fueron establecidas.
Fase de consolidación
Guiados por el mismo líder se ira pasando por cada idea tratando de ampliar, si alguna no quedo bien
escrita la reescribimos y luego se va a debatir si es valida o no, quedando confirmadas si se tienen en
cuenta o no. El resultado final de la fase de consolidación es un listado de posibles ideas a considerar
que ya han sido debatidas, analizadas y quedaron fuera las descartadas porque no eran apropiadas,
útiles o porque se contrapone con otras quedando un conjunto ya clasificado y priorizado de las que
si vamos a tener que tener en cuenta.
Esto se puede hacer mucho cuando el cliente entiende bien de sistemas y que en esta sesión puede
legar a servir su aporte, o cuando el cliente no sabe lo que quiere, entonces un torbellino de ideas
ayuda a tratar de escuchar que ideas va tirando y en conjunto llegar a dislumbrar hacia donde debe ir
el proyecto.
Depende de las características del proyecto se podrá utilizar o no el torbellino de ideas, siendo también
complementario a la entrevista y para el análisis de documentación logrando una buena visión para
desarrollar el sistema.
Ventajas
No es que tenemos una propuesta y nos
quedamos solo en ella, sino que el torbellino
nos va dando una perspectiva mas amplia y esa
interacción con el grupo del cliente y
escuchándolo nos abre la cabeza acerca de lo
que podemos proponer y hacia donde vamos
con el desarrollo del sistema.
Análisis de Sistema Resumen Nicolás Aguirre
Relación entre fuentes de información y técnicas de elicitación
La elicitación es la adquisición
del conocimiento. Conociendo
la fuente que me va a proveer la
información y haciendo uso de
las técnicas y ejecutándolas
obtengo la información, el
conocimiento, el listado de
requerimientos, lo clasifico,
priorizo y paso a trabajar al
siguiente proceso o etapa que
sigue en la etapa de
requerimientos.

UNIDAD 6: ESPECIFICACION DE REQUERIMIENTOS | M.O.D.P | MODELO DE CASOS DE USO |

PROTOTIPO DE INTERFAZ
Especificación
La especificación de requerimiento es una actividad o un proceso, es el mismo concepto, donde vamos
a realizar una descripción completa de lo que nosotros estamos proponiendo de un sistema informática
que cubre esos requerimientos. Esa descripción completa va a estar comprendiendo el
comportamiento deseado del sistema y vamos a completar esa descripción en un documento,
formalizándolo.
El resultado de este proceso es ese documento que vamos a crear, con una descripción con formato
libre o con una serie de diagramas con cierto lenguaje de modelado y vamos a crear la descripción
completa de la solución del sistema que estamos proponiendo. Esa descripción va a formar un
documento que va a tener una forma de contrato que va a servir como acuerdo entre nosotros equipo
de sistemas que estamos proponiendo y el futuro usuario que va a recibir este sistema, considerando
aspectos funcionales y no funcionales además de otras propiedades como performance, confiabilidad,
etc. pero sin mostrar el cómo alcanzara tal funcionalidad.
Cuando nosotros desarrollamos un sistema esta la tarea de análisis y de diseño. Siempre el análisis
debe definir que debe hacer el sistema o que hará el sistema. Hacer especificación esta relacionado
a este concepto de análisis que es el que va a hacer el sistema y vamos a definir el comportamiento
deseado sin entrar en detalle de como se va a llevar a la practica real siendo eso el aspecto de diseño.
Toda esta tarea de ingeniería de requerimiento es donde estamos haciendo análisis de un sistema,
encontramos requerimientos, planteamos una respuesta o comportamiento deseado y eso debe definir
el que debe hacer el sistema sin mostrar el como (programación y como será implementado en la
realidad).
Análisis de Sistema Resumen Nicolás Aguirre
La tarea da como resultado un documento denominado ERS (Especificación de Requerimientos de
Software) que tiene una estructura establecida de forma estándar. En la especificación enunciamos
de forma completa como deseamos que el sistema se comporte, funciones y que datos debe tener.
Actividades en el descubrimiento y especificación de requisitos
Estas actividades se dividen en las siguientes que se alimentan de todo el conocimiento adquirido en
la tarea de elicitación. A partir de esa información recibida, las cuatro actividades que dirigen las tareas
de especificación son las siguientes:
A – Enumerar los requisitos candidatos
B – Comprender el contexto del sistema
C – Capturar los requisitos funcionales
D – Capturar los requisitos no funcionales
A ) Enumeración de requisitos candidatos
Es una actividad donde se ordena, analiza y establece ese listado de requisitos, por eso se llama
candidatos. Los tengo que terminar de ordenar.
Enumerar requisitos candidatos esta relacionado con la información obtenida de la elicitación y es el
planteo de esta primera lista de requerimientos que yo obtengo, entrando a formar parte de candidatos,
tengo que ahondar un poquito más las siguientes actividades y termino definiendo el listado de
requerimientos final.
B ) Comprender el contexto del sistema
Este concepto de comprender el contexto del sistema incluye dos acciones, por un lado, modelar el
negocio y por otro modelar el dominio.
Yo puedo comprender el contexto a partir del modelado de negocio que es el famoso BPMN, en el
tiempo la técnica y la herramienta puede cambiar ya que se encuentran otras maneras de graficar los
procesos de negocio, pero siempre que tenga que entender un sistema debo modelar el negocio bajo
una herramienta conocida.
Cuando estamos desarrollando un sistema y vamos a modelar negocio con algunas de las siguientes
intenciones: para describir cómo es actualmente y tomar conocimientos de los procesos actuales,
mejorar procesos, o para rediseñar procesos. Cuando nosotros estamos haciendo una propuesta de
sistema no solamente va a ser para saber como está funcionando sino que además siempre todo
negocio, todo proceso de negocio es factible de que tenga alguna mejora, entonces, yo puedo
proponer un sistema de información a la vez mejorando el proceso actual de cómo están ejecutando
su actividad en ese negocio o también voy a proponer un sistema haciendo un rediseño puesto que el
mismo quedo obsoleto por distintas circunstancias, necesitando una reformulación., Mi sistema se va
a desarrollar, no como actualmente se esta desarrollando el negocio, sino considerando las mejoras
en el proceso o el rediseño en el proceso. Mi propuesta va a ir caminando de la mano con ese proceso
de negocio mejorado o rediseñado, pero la herramienta es la misma, ya que debemos modelar el
proceso representado como funciona actualmente, la mejora o el rediseño.
La otra parte de esta técnica es establecer el modelo de dominio (Modelo de objetos del dominio del
problema MODP o modelo de objetos del dominio MOD) que significa hacer diagramas de clases de
lo que el sistema debería comprender como atributos, datos, estructuras, comportamientos, siempre
Análisis de Sistema Resumen Nicolás Aguirre
trabajando en la propuesta de soluciones. Dentro de lo que puede completar el modelado del dominio
son los siguientes conceptos cuando hablamos de las clases del dominio, que pueden aparecer como:
• Entidades de negocio que tiene que ver con todo ese negocio u organización, datos, acciones,
transacción que lleva a cabo en función de eso vamos a encontrar clases que completen
información que manejan entidades del negocio. Representan cosas que se manipulan en el
negocio
• Entidades del mundo real y conceptos de los que el sistema debe hace run seguimiento, como
artículos, vehículos.
• Sucesos que ocurrirán o han ocurrido en función de que, si estamos modelando una propuesta
sobre una mejora, sobre un rediseño, tenemos que poder considerar todo aquello que le va a
afectar desde la estructura de datos o desde el comportamiento del sistema. Ejemplos: llegada
de un avión, un siniestro en una compañía de seguros.
La utilidad del modelo de dominio radica en que messirve para la comprensión del problema, ayudando
a los usuarios, clientes, analistas, desarrolladores y oros participantes del proyecto a utilizar un
vocabulario común. Por ejemplo, si yo a la clase la identifico y esta dentro de un dominio que es
hospital, en vez de hablar de una clase persona o cliente, que es muy abierto, le doy un nombre
especifico que sería paciente. Si estoy modelando un sistema de alojamiento en un hotel, la persona
que va a alojarse tiene un concepto que son pasajeros, haciendo una clase con ese nombre. Entonces
voy usando la identificación de clases o atributos con un vocabulario común que hace a ese sistema y
al desarrollo de ese modelo en ese contexto.
¿Cómo me va a ir sirviendo identificar clases en este modelo del dominio? Luego voy a encontrar
requerimiento y después casos de usos. Cuando tengo clases de dominio voy a tener y describir casos
de usos que tienen una relación absolutamente integral, una cosa se corresponde con la otra. Estas
clases también sirven para poder diseñar las ventanas, los prototipos de interfaz de usuario, yo tengo
una definición y una vista del diagrama de clases y luego tendré que diseñar las ventanas del sistema.
También va a servir para seguir avanzando en el desarrollo del sistema para sugerir clases internas
que van a aparecer en el flujo de trabajo de análisis.
Pautas para la construcción del MODP
Incluye y considera todo lo que significa el diagrama de clases, con todo lo que es la simbología de
UML y con toda la concepción del paradigma orientado a objetos.
Cuando construimos un MODP todas las clases tienen que estar en su estado final y refinadas
completamente. Siempre que se construya un MODP tiene que estar completo con la aplicación de los
patrones estructurales.
Siempre que vamos encontrando clases, identificamos atributos asociados a esas clases principales,
pero luego hay que dar una segunda vuelta a ese diagrama encontrando nuevas clases que van
refinando o mejorando el modelo, conocido como refinamiento del diagrama de clases, encontrando
clases de definición o soporte.
Estas clases van a servir para parametrizar, a la larga, todos los valores, términos que un sistema
puede llegar a manejar, para crear listas, valores determinados, tipificar valores, todo eso sirviendo a
la estructuración del sistema de información. Normalmente muchas de esas clases que surgen como
clases de definición o de soporte inicialmente fueron un atributo en un diagrama de clases. Cuando
justificamos identificarlas y separarlas aparecen estas clases de definición o soporte.
Análisis de Sistema Resumen Nicolás Aguirre
Ejemplos de estas clases son Tipo Documento ya que, si vamos a registrar una persona, que tipo de
documento tiene es un valor que puede predeterminarse, parametrizarse estableciendo valores
predeterminados que asume el Tipo Documento pudiendo considerar DNI, Pasaporte, Cedula, etc. y
de esa forma se pueden trabajar todas estas clases de soporte, otros ejemplos:

Todos los valores que puedan ser refinados, parametrizados o tipificados van a formar ora clase.
Género y Sello discográfico puede
parametrizarse estableciendo valores
predeterminados, convirtiéndose en
clases de soporte.
En cambio, si se fijan los otros
atributos pueden variar dependiendo
del disco, no pueden parametrizarse
en clases con valores que, si o si va a
tener, si no que cambian como por
ejemplo el código del disco, el
nombre, etc.

Métodos de seteo para el MODP

Aparece a medida que se va implementando. Por cada atributo de cada clase existen los métodos de
seteo que es la forma en la cual interna y finalmente en la implementación del código se trabajan los
valores que van a asumir los atributos. Esos métodos son conocidos como get que es el concepto de
Análisis de Sistema Resumen Nicolás Aguirre
obtener y mostrar y el set que es para setear, es decir, modificar, tomar o darle un valor al atributo,
siendo concretamente como se va a implementar. Se le indica a una sola clase porque no nos metemos
en el detalle de como vamos a implementarlo al sistema, y se vuelve poco practico poner las mismas
dos métodos de seteo para cada clase. Entonces para simplificar y no ignorar el concepto del método
de seteo, se elige la clase con la clase con menor cantidad de atributos y agregamos el get y set con
una nota que diga “Métodos de seteo extensivos al resto de las clases”.
Los métodos get y set en esa foto son
mostrar y tomar respectivamente.
Con eso nos ahorramos de poner siempre
los mismos métodos de seteo en cada clase.
CREAR NO ES MÉTODO DE SETEO.

C) Capturar los Requisitos Funcionales

Tenemos la lista de requisitos candidatos y vamos a clasificar esos requisitos en funcionales y no
funcionales, el concepto de capturar los requisitos funcionales es que vamos a crear un modelo y crear
una descripción detallada transformando a partir de esos requisitos funcionales, identificando casos
de usos y creando un modelo de casos de usos. Esta palabra que se había presentado antes, dentro
de las características del proceso unificado, que está dirigido por casos de usos, lo que se hace en la
especificación es: identificar los casos de uso y crear un modelo de casos de usos a partir de los
modelos de requisitos funcionales.
Recordemos que los requisitos funcionales representan las funcionalidades que el sistema
comprenderá
D) Capturar los requisitos No Funcionales
Es el listado de todas las restricciones que haya que considerar del sistema que vamos a proponer y
desarrollar, es el concepto dentro de esta actividad que considera, en la clasificación de estos
requisitos aquellos que entran en la categoría de no funcionales, que consideran todas las restricciones
que va a tener el sistema a desarrollar.
Nosotros vamos a partir de ahora identificar y modelar cosas de usos que capturan esencialmente los
requisitos funcionales y la especificación de requisitos normalmente trabaja con describir el
comportamiento deseado del sistema a partir de casos de uso, nunca perdiendo de vista las
restricciones del sistema por eso que van de la mano estos casos de uso y la descripción de los
mismos con algunas consideraciones de los aspectos no funcionales porque no podemos describir
cosas ideal, siempre vamos a tener que ajustarnos a todas esas restricciones que acompañan la
propuesta del sistema
Modelado de casos de uso
El caso de uso se entiende como una forma de contar historias acerca de los requerimientos
funcionales con lo que necesitan que use o haga el sistema. Desde allí vamos a encontrar casos de
usos a partir de las funciones que hemos encontrado que serían requerimientos funcionales y vamos
Análisis de Sistema Resumen Nicolás Aguirre
a contar como se lleva a cabo eso. Desde un punto de vista so historias acerca de cómo las personas
u otras cosas usan el sistema para realizar ciertas tareas.
Por ejemplo, cuando hacemos un listado de requerimiento ponemos el conjunto de todas las funciones,
primero con un listado global de requerimiento funcionales y luego detallado. Por cada requerimiento
de esa lista de tipo funcional va a contar la historia, va a contar como hace esa persona para registrar
en ese sistema un cliente, por ejemplo.
Una historia ayuda a mantener el contexto visible y el valor para el usuario de forma claro, siendo el
usuario el futuro persona o algo mas que va a hacer uso del sistema. El caso de uso cuenta como esa
persona u otra cosa ejecuta un conjunto de tareas y va a lograr cumplir esa función como registra un
cliente, modificar cliente, generar listado, todas las distintas funciones que hemos listado en ese listado
de requerimientos funcionales.
Ese caso de uso cuenta la historia, pero lo importante es que 2use un lenguaje común en términos no
técnicos, que sea entendible para el usuario, pero dentro de un lenguaje de lo que se maneja en ese
negocio.
Los casos de uso cuentan historias acerca de los requerimientos y son un buen modo de organizar los
mismos. Siempre que nosotros desarrollemos un sistema hay una tarea de requerimiento que es igual
independiente de la tecnología. Las metodologías agiles proponen otra forma de contar estas historias,
en el tiempo puede ir cambiando la herramienta que me propone como describir, pero siempre que
piense un sistema tengo que poder tener una herramienta para describir y contar como pienso que se
va a ejecutar el conjunto de pasos para logar el objetivo de esa función que yo identifique que un
sistema debe hacer.
Definición de caso de uso
Se define como aquello que describe los comportamientos de un sistema bajo ciertas condiciones en
el que el sistema responde a los requerimientos de los involucrados. Concretamente, los casos de uso
son fragmento de funcionalidad que nosotros describimos y va a ser algo que el sistema ofrece, algo
que el sistema va a hacer. Todo caso de uso tiene un objetivo y obtiene un nuevo resultado de valor
para sus actores.
Un caso de uso son fragmentos de funcionalidad que el sistema ofrece, que cumplen con un objetivo
y obtiene un resultado de valor para sus actores, le sirve a esos actores que es aquel que va a necesitar
de la función de ese sistema.
Simbología del caso de uso y nomenclatura
Se completa la oración con el objeto correspondiente
a la acción que queremos indiciar

Concretamente, un caso de uso se puede encontrar partiendo de la definición de requerimientos y

dentro de los funcionales se los encuentra, teniendo que dar un nombren con un verbo en infinitivo y
un objeto de lo que queremos hacer, y cuando pensamos en un caso de uso es un fragmento de
funcionalidad que tiene un objetivo que agrega valor a quien está ejecutando esa acción y por detrás
del caso de uso va a tener una descripción, una especificación de una secuencia de acciones que el
sistema va a llevar a cabo en interacción con sus actores y va a ir desarrollando la cantidad de pasos
Análisis de Sistema Resumen Nicolás Aguirre
hasta lograr cumplir el objetivo y obtener el resultado. El caso de uso representa la forma en que los
actores usan el sistema.

Partimos de requerimientos funcionales detallados y por cada caso de uso identificado se va graficando
con una elipse y dándose el nombre con la notación correspondiente. No se deja de tener en cuenta
los requerimientos no funcionales.
Nosotros con los casos de uso construiremos un diagrama de casos de uso. Es un diagrama dentro
de lo que es UML, lenguaje modelado unificado, que me da una serie de diagramas a realizar y un
lenguaje estándar para el modelado correspondiente.
Este diagrama de casos de uso nos permite comunicar el alcance del sistema, tener un diagrama con
un formato gráfico, y por otor lado proveer a todo el equipo de una descripción de todos o parte en
función de cómo voy avanzando de los requerimientos de un sistema.
Dentro de lo que es UML el diagrama de casos de uso está ubicado dentro del grupo de diagrama de
comportamiento, muestra un aspecto estático y dentro de las distintas vistas que hay pertenece a la
vista de casos de uso.
Modelado de casos de uso
Un diagrama de casos de uso está formado por elementos para poder construir el mismo.
Por un lado tiene los casos de uso, por otro lado los actores y por últimos las relaciones que van a
poder establecerse entre actores, entre actor y caso de uso y entre casos de uso.
Análisis de Sistema Resumen Nicolás Aguirre
Definición de actor
Un actor es un roll, siempre que estemos hablando de un diagrama de casos de uso, un actor va a
estar representado por un rol de alguien que sería un usuario que va a jugar en el sistema y en relación
con un caso de uso. Es un rol que juega un usuario en un caso de uso. Ese rol puede ser desempañado
por personas, pero no son los únicos que cumplen esta función pudiendo tener otro sistema u otros
dispositivos de hardware
Un actor es un rol que juega un usuario en un caso de uso, todo aquel que haga uso del sistema e
interactúe con el sistema va a ser un usuario que tendrá el rotulo de actor en la ejecución de un rol.
En definitiva, el rol es cada usuario que interactúa con el sistema y puede llegar a desempeñar alguna
función o puede llegar a desempañar varios roles por cada rol diferente que yo identifique voy a
encontrar un actor. Tal vez nos toque conocer negocios en donde un negocio tenga una persona que
haga de secretaria, de atención al cliente y hace algo administrativo, entonces cuando una misma
persona te ejecuta muchas funciones en cuanto a negocio es importante distinguir el rol diferente en
función de tareas relacionadas diferentes. No es lo mismo tener funciones y ejecutar un rol en atención
al cliente que tenga que ver con registra cliente, una venta y consultar stock a realizar tareas
administrativas que tengan que ver con una cuestión contable o financiera. La idea es encontrar roles
diferentes.
Los roles los encontramos como un usuario que ejecuta una serie de tareas o que desempeña una
serie de tareas relacionadas, entonces, en función de eso encontramos roles y con eso encontramos
actores y es ponemos un nombre.
La simbología para representar un actor es una figura de una persona, ya sea que sea una persona,
dispositivo de hardware u otro sistema, siempre es un dibujo de una persona.
Siempre que vamos encontrando los actores,
esto nos lleva a establecer un limite entre el
sistema y su ambiente porque el sistema es las
funciones que tenga y el actor es alguien que
desde afuera actúa y accede al sistema
entonces de alguna forma establezco el actor estoy estableciendo el link entre el sistema con quien se
relaciona y que funciones ejecuta.
Cada persona que vaya a interactuar con el
sistema es un futuro usuario de su sistema y
tenemos que encontrar el rol que desempeña
y en base a eso identificaremos los actores.
Si hablamos de un sistema de ventas habrá
alguien que desempeña la tarea de atender
al cliente, entonces tendrá un actor que
tendrá un rotulo que comenzara con
responsable de, encargado de, van
escribiendo y dándole un nombre a ese actor.

Los distintos roles que ejecuten las personas y que tengan que hacer uso del sistema nos van a servir
para encontrar actores.
Análisis de Sistema Resumen Nicolás Aguirre
Vayamos a un requerimiento funcional, que es registrar la venta de productos, ese requerimiento
funcional me va a crear un caso de uso que seria registrar la venta y como un caso de uso es una
secuencia de acciones que cumplen un objetivo y obtienen un resultado de valor para el actor, lo que
significa que se tiene que registrar la venta. Cuando llega el momento del cobro necesita cobrar con
tarjeta de crédito, pidiendo la autorización pasando la tarjeta con el posnet y conectándonos a un
sistema que nos da la confirmación del crédito del cupón de la compra. Eso que estamos relatando
desde que conocimos el negocio, establecieron el listado de requerimientos, encontraron el caso de
uso y encontramos dicha conexión a otro sistema, tiene que representarse como un actor y se le pone
en el nombre representativo como: “sistema administrador de tarjetas de crédito” y de esa forma,
cuando encontramos actores nos podemos llegar a encontrar con actores que son otro sistema que
va a estar relacionado con el sistema actual nuestro.
Un actor puede ser un rol desempeñado por personas, otro sistema u otros dispositivos de hardware,
nos puede tocar el desarrollo de un sistema que tenga que estar conectado a un dispositivo de
hardware que le de una entrada al sistema que de alguna forma el sistema debe ejecutar alguna
función y se llama dispositivo de hardware porque no hay una persona entrando a una opción de
sistema, hay otro componente que hace lecturas o algún envió de información y el sistema ejecuta una
función. Un ejemplo es el sensor de temperatura.
Vamos a tener a veces acciones en el sistema que son alertas o procesos automáticos, que no son de
generación automática porque la función de cualquier sistema no surge de la nada, surge porque algo
lo dispara, entonces cuando el tiempo es la situación en la que ocurre el disparador de ese evento, de
ese caso de uso, estamos en presencia de un actor que puede llamarse tiempo, temporizador o reloj,
que es un actor que cada cierto periodo del tiempo ejecuta una función del sistema. Esto cuenta como
otro dispositivo de hardware.
Relaciones entre caso de uso y actor
Una relación es una flecha que conecta un actor con su caso de uso.
Tengo una persona que atiende al público y que hace
la venta de artículos, hay un listado de requerimientos
funcionales porque yo quiero administrar el registro
de las ventas y hay un caso de uso donde a partir del
requerimiento funcional encontré yo el caso de uso.

Cuando yo digo que hay una relación entre actor y caso de uso grafico esta relación que es una flecha
donde el actor instancia o inicia el caso de uso, eso es lo que estoy representando. Si el responsable
de venta va a entrar a un sistema, a una pantalla ya va a ejecutar una función estoy modelando esta
flecha de ingreso y si va a haber interacción con ese caso de uso no voy graficando múltiples flechas,
solamente grafico la flecha en su estado inicial de quien inicia la acción en el caso de uso.
El caso de uso es un fragmento de funcionalidad que tiene un objetivo, ejecuta una secuencia de
acciones y obtiene un resultado de valor para el actor. Esto quiere decir que hay alguien, que en este
caso el actor es un responsable de ventas , una persona que va a iniciar el caso de uso para ejecutar
esa función, Cuando especificamos requerimientos identifico el caso de uso, el fragmento de
funcionalidad, cada caso de uso va a tener una secuencia de acciones, es una forma de contar una
Análisis de Sistema Resumen Nicolás Aguirre
historia de como el sistema ante una petición hace un conjunto de acciones y le da un resultado.
Estamos diseñando un sistema, todo caso de uso tiene una descripción de como ejecuta el conjunto
de acciones, describiendo una secuencia lógica que se va a transformar en un programa con lenguaje
de programación. Cuando pensamos e identificamos casos de uso estamos buscando las funciones
de un sistema y para entenderlo e identificarlo correctamente tenemos que pensar que el caso de uso
es un conjunto de acciones donde la especificación de requerimientos estará escrito con un lenguaje
común diciendo la secuencia de pasos que ejecuta y cuál es el resultado que obtiene.
A su vez cada caso de uso va a tener una o varias pantallas, prototipos de interfaz, que van a permitir
que yo diseñe como va a mostrarse el sistema y que datos va a manejar, nosotros para identificar
correctamente un caso de uso tenemos que ir pensando que significa y hacia donde vamos
Podemos clasificar los actores según un tipo: actor primario y secundario. En la mayoría de los
diagramas de uso vamos a tener todos o casi todos como actor primario, siempre hay. Actor secundario
puede haber ocasionalmente dependiendo del dominio del problema y la situación particular
Actor Primario
Actor que tiene un objetivo claro y que va a ser tenido en cuenta y considerado a través de la ejecución
de algún cas de uso y va a ejecutar y va a concretar esa necesidad que tiene con la ejecución de
alguna función en ese sistema. Normalmente un actor primario es aquel que instancia o inicia el caso
de uso. Si yo tengo una relación entre actor y caso de uso y esa relación va a e inicia el caso de uso
estoy en presencia de un actor primario.

La secuencia de pasos que va a tener este caso de uso, identifico a la persona titular y al vehículo y
tengo que proceder a la baja, no se da la baja así nomás necesito la autorización de algún directivo
donde me de el okey porque significa que por algún concepto se fue del municipio entonces necesita
una autorización. Entonces ahí aparece el actor secundario siendo aquel que de alguna forma va a
participar o colaborar con ese caso de uso y por lo cual el sistema necesita de ese actor para poder
completar el conjunto de acciones a completar.
Actor Secundario
Es de quien el sistema necesita ayuda o un determinado comportamiento para cumplir con el objetivo
del actor primario.
En definitiva, aquel actor que tenga objetivo y que instancia un caso de uso y ejecuta un conjunto de
acciones es el actor primario. Cuando ese caso de uso en el conjunto de acciones el sistema necesita
la intervención de un segundo actor para concretar sus acciones aparece este rol secundario que sería
la identificación de un actor secundario. El actor primario seria el encargado de cuentas automotor y
el secundario el director de rentas.
Análisis de Sistema Resumen Nicolás Aguirre
Cuando yo voy a cobrar con factura permito
el pago con tarjeta de débito. Todo pago con
tarjeta necesita de alguien que autorice ese
pago, entonces tengo un cajero que está
cobrando, una funcionalidad que es el cobro
de facturas y en algún momento necesito la
autorización de ese debito con un sistema o
un dispositivo que autorice el debito teniendo
ese actor secundario. Son ejemplos para
tener en cuenta y normalmente el actor
secundario es pocas veces utilizado y
siempre tendremos actor primario.

Relación entre actores

Consideramos aquella que se llama generalización de actores. Este término generalización es uno
que venimos usando, en el diagrama de clases cuando hablábamos de jerarquía y herencia. Entre
actores también vamos a usar el concepto de herencia que va a estar reflejada entre un actor padre y
varios actores hijos.
Cuando identificamos uno o más actores que tienen un rol en común para un caso de uso. Cuando
vemos una situación que podemos construir una estructura de herencia donde se lleva el actor padre
el rol común y tenemos actores hijos que van a tener la herencia del padre mas comportamiento o rol
propio o articular estamos en presencia de poder representar una generalización de actores.
Pueden definirse categorías generales de actores y especializarnos a través de relaciones de
generalización, aplicando la herencia. Los actores especializados son los que vamos a llamar actores
hijos que heredan el comportamiento del actor padre. Cuando tengamos una relación de
generalización la simbología es la misma notación, una flecha cerrada y con un relleno en blanco sin
pintar. Cuando nosotros queremos reflejar una generalización la simbología de esa flecha cerrada y
en blanco es la misma. Según lo que este entre extremos si es una generalización entre clases
justamente tenemos clases padres , clases hijos y si es una generalización de actores tendremos actor
padre y actores hijos.
Lo que estamos analizando con esta representación es que, si un caso de uso es instanciado por el
actor padre, quiere decir que el actor padre va a tener una relación con uno o mas casos de uso quiere
decir que ese caso de uso puede ser instanciado por cualquiera de sus actores hijos. Pero por otro
lado podemos tener otros casos de uso donde únicamente el actor hijo lo va a instanciar.
Cuando tenemos que aplicar un concepto de herencia por algún rol que es compartido, entonces el
comportamiento de los casos de uso que accede ese rol común va a ser un actor padre y los hijos
heredan la relación o la instanciación de esos casos de uso más una relación o acceso a casos de
usos que solo accede el actor hijo.
Análisis de Sistema Resumen Nicolás Aguirre

Inicialmente en este análisis del sistema que estamos viendo tenemos un rol que es el vendedor de
mostrador y otro rol que es el viajante, pero en común tiene que ya sea que la venta sea directa o que
el viajante tome el pedido y haga la venta también hay un rol común que es el de acción de la venta
que puede ser responsable de venta o vendedor. Cuando estamos en presencia de encontrar un
comportamiento común o un conjunto de casos de uso que son instanciados por un rol compartido es
donde creamos este actor que sería el actor padre.
El vendedor es un rol que va a ser la representación de nuestro actor padre va a instanciar el caso de
uso que se denomina registrar venta y graficamos acá los actores hijos, significando que el vendedor
va a heredar el comportamiento de su actor padre que significa que todos los casos de uso que accede
el padre también los va a heredar y acceder el actor hijo, igual para el viajante.
Además, podrá haber otros casos de uso que solo va a acceder el viajante como cuando consulta las
zonas de distribución o cuando tenga que consultar los clientes por zona serán otros casos de uso que
solo va a acceder el viajante, por ejemplo. Así también ocurre con el vendedor de mostrador con sus
casos de uso propios.
Esta construcción de obtener una generalización de actores se da cuando vamos encontrando casos
de usos y van viendo que para este actor hace esta acción y para este otro actor también hace esta
acción y entonces ahí empezamos a encontrar este comportamiento común o ese acceso a casos de
uso común y es ahí donde empieza a construir esa generalización.
Cuando tengamos que dos o más actores acceden a una misma funcionalidad, a un mismo caso de
uso, estamos en presencia de poder aplicar la generalización de actores identificando un nuevo actor
que va a ser el actor padre. Y luego se agrega esa relación de generalización, diciéndose que el actor
hijo hereda el comportamiento del actor padre significando acceder o instanciar los mismos casos de
uso que el actor padre está iniciando o instanciando.
Análisis de Sistema Resumen Nicolás Aguirre
Para poder construir un diagrama de casos de uso existe una serie de actividades para la captura y
especificación de requerimientos aplicando el PUD (Proceso unificado desarrollo) y usando los
diagramas de UML 2.0.
Cuando nosotros estamos en este punto de empezar a construir modelos de casos de uso es porque
ya hemos hecho ese conjunto de actividades y porque hemos hecho nuestras tareas de elicitacion,
entonces todas las consideraciones entradas y conocimientos necesarios para construir casos de uso
debemos considerar lo siguiente:
Tengo un objetivo porque tengo una propuesta
y debo cubrir una serie de funciones para
considerar y lograr desarrollar un sistema.
Tengo un listado de requerimientos funcionales
y no funcionales, también tenemos el modelado
de negocio ya sea solo descripción del modelo
actual, una mejora o una reingeniería y por otro
lado tenemos modelado el dominio que sería el
diagrama de clases.

Mi listado de requerimiento es mi puntapié inicial para encontrar las soluciones, los casos de uso deben
cubrir esos requerimientos y cumplir con e objetivo del sistema de información, a la vez todos esos
casos de uso van a cumplir funciones según el conocimiento que teneos del negocio y por otro lado
vamos a ir encontrando el modelo de casos de usos y el dominio son paralelos porque uno va a
encontrando ambas cosas.
Para ir construyendo este modelo de casos de uso nuestra primera tarea es a partir de todo este
panorama, conocimiento y esta propuesta que estoy queriendo avanzar, el primer trabajo es encontrar
actores y casos de uso. Voy a continuar con estructurar el modelo de casos de uso, que es hacer uso
de las relaciones entre casos de uso, voy a ir construyendo el diagrama de uso y luego por cada
diagrama que identifique y genere un diagrama vamos a describir los casos de uso.
Encontrar actores y casos de uso
Al encontrar actores y casos de uso vamos a hacer una serie de tareas, de trabajos sobre lo que es
ese conocimiento y planteo, encontrando actores y describiendo el rol de los mismos, además de
encontrar casos de uso y definiendo objetivos o una descripción breve de cada caso de uso,
poniéndole nombre y objetivo.
Estructurar el modelo de caso de uso
Una vez que identificamos estos actores y casos de uso vamos a empezar a relacionarlos agregando
relaciones entre actores, actores y casos de usos y entre casos de uso como la inclusión, extensión o
generalización.
Construcción del diagrama de casos de uso
Se hace la construcción del diagrama, creando uno completo con todos los actores, los casos de uso
y el uso de los distintos tipos de relaciones.
Análisis de Sistema Resumen Nicolás Aguirre
Describir casos de uso
Se hace una plantilla con un formato para describir pasos de uso.
Modelado de casos de uso
Para encontrar actores se consideran estas preguntas que nos pueden ayudar a encontrarlos.
¿Quién usara alguna funcionalidad? Ese usara hace referencia a aquellos futuros usuarios, cualquiera
que tenga que interactuar con el sistema y que necesite algo puede ser candidato a actor, lo vamos a
analizar y si es concreto lo vamos confirmando en diagrama.
¿Quién proveerá usara o quitara información? Esto tiene que ver con que habrá datos en el sistema
que se van a registrar, que se consultaran, que se modificaran, eso también nos dará pautas para
encontrar actores.
¿Los recursos humanos y roles identificados en el modelo de negocio harán uso del sistema? Nosotros
identificamos una serie de recursos humanos que son candidatos de ser actores en el diagrama de
casos de uso, pudiendo identificarlos porque si hacen uso del sistema se transforman en un actor con
un rol.
¿Quién esta interesado en esos requerimientos? Hay muchas funciones habiendo que encontrar los
que necesitan el resultado de ejecutar una función un caso de uso que cubra un requerimiento,
encontrando los interesados en esos requerimientos.
¿Algún dispositivo enviara o tomara datos de este sistema? Con eso podemos ir encontrando algún
dispositivo de hardware, algún concepto más allá de personas físicas que trabajen con el sistema.
¿Cuáles son los recursos externos del sistema? Con que otros sistemas puede llegar a interactuar
para saber que debemos tener cómo función en el caso de uso.
¿Quién dará soporte y mantendrá el sistema? Lo más rápido que identificamos son las transacciones
que ejecuta el sistema, peor si yo aparte no tengo otras funciones que vayan registrando toda la
información el sistema no va a funcionar.
¿En que parte de la organización será usado el sistema? Eso también puede disparar algún otro
recurso humano, algún otro rol aparte del modelado de negocio que me pueda dar alguna otra
indicación que quiera hacer acceso a ese sistema.
Una vez que los actores están identificados tengo que hacer la descripción del rol, esto significa
describir en forma narrativa ese actor que rol cumple en relación al sistema, siempre cada actor tendrá
un nombre y un párrafo donde redactemos la descripción de ese rol que cumple ese actor en el
sistema.

Tenemos que redactarlo de una forma tal que sea resumida pero completa de las funciones que lleva
a cabo ese actor en el sistema.
Análisis de Sistema Resumen Nicolás Aguirre

Un diagrama de clases a futuro conforma las bases de datos de un sistema y un caso de uso a futuro
van a formar las funciones automáticas, lo que va a programarse, codificarse y que va a interactuar
con ese diagrama de clases con la base de datos para manipular los datos, para guardarlos, para
consultarlos y demás. El resultado final de esta tarea de encontrar casos de uso es saber identificar
casos de usos que representen fragmento de funcionalidad o una secuencia de acciones concretas
que cumple un objetivo y que genera un resultado que produce algo de valor para el actor.
Categorías de casos de uso
Cuando vamos encontrando los casos de uso que hacen las principales funciones del sistema,
estamos identificando casos de uso esenciales. De alguna forma voy a encontrar 5,10,20,100 casos
de uso y si corresponde a las funciones principales de lo que desarrolla ese sistema para esa
organización estamos ante casos de uso esenciales, comprendiendo los principales procesos que va
a ejecutar el sistema de información. Pero un sistema no termina solo con la identificación de casos
de uso esenciales, se completa con una gran cantidad de otras funciones que se denominan casos de
uso de soporte, comprenden todo lo complementario para que un sistema ejecute el conjunto de
acciones de una forma completa. Por ejemplo, nosotros registramos un cliente en un proceso de
ventas, siendo un caso de uso principal, yo los datos del cliente los quiero mantener y si después de
un tiempo ya el cliente no va a ser mas cliente de mi negocio lo quiero dar de baja así limpio mi cartera
de clientes. Esa información de poder modificar o de poder dar de baja entraría en esta categoría de
soporte, porque completa la funcionalidad de caso de uso esenciales que es la funcionalidad principal
para poder ejecutar las principales funciones de ese negocio que el sistema debe comprender, los
casos de uso esenciales son los primeros en ser descubiertos y luego vamos encontrando estos otros
Análisis de Sistema Resumen Nicolás Aguirre
que son los de soporte. Si tenemos el listado de requerimiento completos vamos a encontrar en los
detallados algunos que son esenciales porque hacen el principal circuito de ese negocio.
Esenciales
Describen la funcionalidad principal que tiene que cumplir el sistema. Comprenden los principales
procesos que debe ejecutar el sistema de información.
De Soporte
Comprenden la funcionalidad que surge a partir de analizar aquello que se necesita para que puedan
funcionar los casos de uso esenciales, que completa la funcionalidad el sistema.
Definir objetivo o describir brevemente los casos de uso
A medida que se van identificando los casos de uso se esbozan unas pocas palabras explicando cada
uno de ellos a modo de objetivo del caso de uso o se describe brevemente cada caso de uso con
algunas frases que resumen las acciones del mismo.
A cada caso de uso que hemos ido encontrando le vamos a dar un numero cuando tengamos el
diagrama completo, el nombre según la notación y de ese objetivo una breve descripción y a medida
que vamos avanzando vamos a ir luego haciendo una descripción en fino de cada caso de uso. Estas
son unas pocas líneas que hagan a la definición del fin o meta de ese caso de uso.

Tipos de casos de uso

Se pueden clasificar en concreto y abstracto. Los concretos son aquellos iniciados por el actor y ejecuta
un conjunto de acciones completos, yo tengo un actor identificado cuando instancia en forma directa
al caso de uso estamos en presencia de un caso de uso concreto, es cuando el actor inicia ese caso
de uso.
Cuando el caso de uso para iniciar va a ser necesario que otro
caso de uso ejecute la llamada y ahí incorporo una relación
entre casos de uso, pero para que este caso de uso inicie es
necesario que otro caso de uso tenga la necesidad y dispare
el evento de inicio de este caso de uso y en general un caso
de uso que sea abstracto nunca es iniciado por un actor.
Análisis de Sistema Resumen Nicolás Aguirre
Estructurar el modelo de Casos de Uso
Para poder construir un diagrama de caso de uso los casos de uso se relacionan con actores, pero a
la vez podemos encontrar relaciones entre los mismos casos de uso, no siempre van a estar las tres
presentes depende del modelo del diagrama que estamos haciendo en cuales haya necesidad de
hacer uso de las mismas.
Cuando nosotros vamos pensando los casos de uso vamos a encontrar algún conjunto de acciones o
una secuencia de pasos que están relacionadas algún concepto común entre dos o mas casos de uso,
encontrando funciones compartidas. O por otro lado vamos a encontrar funciones que se van a dar
según cierta condición o son opcionales o son situaciones adicionales entonces en función de el
dominio que estemos modelando, la situación de los casos de uso que vamos encontrando y la relación
entre los mismos pueden surgir una o varias de estas.
Inclusión
Una relación de inclusión se define como aquel caso de uso base incorpora explícitamente el
comportamiento de otro caso de uso, en este caso el del caso de uso incluido en algún lugar
especificado del caso de uso base. Una inclusión es cuando nosotros tenemos un caso de uso, cada
vez que identifiquemos el caso de uso debemos identificar la secuencia de acciones y cuando
pensemos la secuencia de acciones podemos encontrar un conjunto de acciones mas pequeño dentro
de ese caso de uso donde pueden ocurrir dos cosas: que para este caso de uso A y para un caso de
uso B el conjunto de acciones es común entonces cuando yo encuentro dos o mas casos de uso con
un comportamiento común yo puedo abstraer, sacar ese conjunto de acciones, a un nuevo caso de
uso y establezco una relación de inclusión.
El caso de uso inicial o ese caso de uso que tenia toda la secuencia de acciones es el que se denomina
caso de uso base y el nuevo caso de uso que yo encuentro que cumple con las condiciones de casos
de uso, con toda la definición va a ser el caso de uso incluido.
También existe otra posibilidad en donde podamos establecer la relación de inclusión, que es cuando
es muy complejo el caso de uso que estamos escribiendo cuando hace esa secuencia de acciones y
existe la posibilidad de abstraer el comportamiento a otro caso de uso y de esa forma dividir el caso
de uso en dos partes disminuyendo la complejidad de un caso de uso.
El caso de uso incluido o el caso de uso de inclusión puede estar instanciado o no por un actor y
siempre va a estar relacionado con un caso de uso base.
La forma de graficar una inclusión es con
esta línea que es una flecha discontinua,
es una relación del tipo de dependencia,
va a llevar un nombre sobre esa flecha
que puede decir include, inc dependiendo
de la herramienta usada. En un extremo
en donde no esta la punta de flecha es el
caso de uso base y hacia donde se dirige
la flecha es el caso de uso incluido.
Concretamente, una relación de inclusión
puede surgir cuando existe un comportamiento común que dos o mas casos de uso tienen yo lo llevo
a un nuevo caso de uso y entonces aprovecho, reutilizo y defino una sola vez ese comportamiento,
Análisis de Sistema Resumen Nicolás Aguirre
por eso se llama relación de inclusión o relación de uso. La otra es para disminuir la complejidad de
un caso de uso muy complejo entonces puedo dividirlo en dos y llevo una situación al caso de uso
incluido y dejo en el caso de uso base otra parte de conjunto de acciones que disminuyo la complejidad
del mismo.
Cuando tengo dos o mas casos de uso en donde tienen la secuencia de acciones que es común, que
es igual, en ese caso puedo llevar ese comportamiento a un nuevo caso de uso para aprovechar
porque si sigue los mismos pasos en la misma secuencia de acciones significa que estos dos casos
de uso base (foto de arriba de modificar y eliminar cuota) van a ejecutar esa funcionalidad común
(registrar justificación) y la defino una sola vez y no la repito varias veces, este trabajo de relación de
inclusión tiene una finalidad de mejora del modelo y de la estructura del diagrama de casos de uso.
En el segundo ejemplo dejo en un caso de uso un conjunto de acciones que estén relacionadas y que
puedan cumplir un objetivo y hago una abstracción de un comportamiento que en si mismo puede ser
otro caso de uso, de esta forma reparto el conjunto de acciones en distintos casos de uso y manejo la
complejidad del mismo.
Siempre que identificamos un caso de uso debemos pensar el objetivo del mismo y la secuencia de
acciones que comprende porque de esa forma es como va a ir encontrando si tiene comportamiento
común o si es complejo y puede desagregarse.
Relación de extensión
Indica que un caso de uso base incorpora implícitamente el comportamiento de otro caso de uso.
Concretamente, cuando es una extensión se estaría considerando el caso de uso base se puede
ejecutar en una forma aislada o si se cumple una condicional, opcionalmente, dada cierta alternativa
o dada cierta consideración se ejecute el otro caso de uso. Ese es el concepto de la extensión, yo
estoy ejecutando un conjunto de acciones y dado una situación puede ejecutarse o no ese otro caso
de uso.
Normalmente el caso de uso base puede ejecutarse aisladamente, pero bajo ciertas condiciones su
funcionalidad será extendida por la del caso de uso de extensión. Una relación de extensión se utiliza
para modelar una parte opcional de un caso de uso, modelar un subflujo separado que solo se ejecuta
bajo ciertas circunstancias.
La exension también es una flecha discontinua igual que la inclusión, por eso es importante que lleve
el nombre de esa relación establecida, pudiendo decir extend o ext o también la palabra ampliar
dependiendo de las distintas herramientas.
Yo voy pensando la secuencia de acciones cuando voy identificando el caso de uso y puede ser que
ese caso de uso tenga otro conjunto de acciones donde se ejecuta según dadas cierta condición un
control al respecto de algo.
Análisis de Sistema Resumen Nicolás Aguirre
Una relación de extensión siempre la punta de flecha apunta al caso de uso base, al revés que la de
inclusión. Es contrario a lo que uno podría pensar. Indica que bajo cierta condición en algún momento
se podría ejecutar ese conjunto de acciones.
Cuando haya inclusiones o extensiones en donde el caso de uso no tiene relación directa con un actor
es un caso de uso abstracto y un caso de uso concreto es cuando su instanciación directa esta iniciada
por un actor.
La extensión es un caso opcional, dada cierta condición o una ruta alternativa, no siempre se ejecuta
en el caso de uso base que viene haciendo su conjunto de accione y si necesita ejecuta y hace la
llamada al caso de uso extendido y sino continua, todo depende de la situación. En la relación de
inclusión siempre el caso de uso base ejecuta y llama al caso de uso incluido. La extensión es opcional
y la inclusión siempre se da.
Generalización entre casos de uso
Cuando hablamos de generalización entre casos de uso lo que vamos a estar trabajando es el
concepto de herencia de lo que es una secuencia de acciones o del comportamiento de un caso de
uso padre puede heredar a casos de usos hijos. De los 3 tipos de relaciones entre casos de uso, esta
es la menos utilizada.
La simbología como es generalización tiene la misma representación con una flecha blanca,
cambiando únicamente que a ambos extremos van a haber casos de uso. Donde orienta la punta de
la flecha va a ser el caso de uso padre y en el otro extremo están los casos de uso hijos.
Un caso de uso hijo hereda el comportamiento del caso de uso padre. Ese caso de uso hijo puede
modificar agregar ese comportamiento agregado porque ese es el concepto de los hijos, pasa que al
hablar de los casos de uso hablamos de la secuencia de acción, estos heredan la secuencia de acción
y alguna podría estar adaptada, modificada y seguro le agregan comportamientos que le son propios.

Estos son dos casos de uso diferenciados, pero tienen algo en común, entonces allí es donde surge
este concepto de caso de uso padre que va a tener alguna secuencia de acciones que son iguales
para los casos de uso hijos, esa secuencia de acciones que se van a heredar y que son iguales se
escriben como secuencia de acciones o se identifican como secuencia de acciones en el caso de uso
padre. En el caso de uso hijo lo que va a hacer es heredar ese comportamiento y le agrega el suyo
propio.
Análisis de Sistema Resumen Nicolás Aguirre
Representar gráficamente el modelo de casos de uso
Es ir uniendo todo lo que vamos identificando en un único diagrama común y completo. Los diagramas
de caso de uso van a mostrar o va a modelar el comportamiento de un sistema o de un subsistema,
un subsistema porque cuando el sistema que esta modelando es muy grande (500 casos de uso) se
hacen diagramas parciales porque sino es complejo un diagrama con tanta cantidad de casos de uso
y las líneas no quedan tan claras.
Los diagramas de caso de uso van a modelar el comportamiento del sistema o por parte de un
subsistema con todo lo que considera. Va a tener en cuenta caso de uso, actores y todas las relaciones
que hemos visto.
Eso es la construcción de un diagrama de caso de uso, no va a salir de primera la construcción directa,
tiene una serie de vueltas donde uno identifica los esenciales que es lo primero que se deduce, en un
trabajo real yo hice el trabajo de elicitación, modele la propuesta con un listado de requerimientos,
estoy con un modelo de negocios ya organizado, voy haciendo en paralelo el diagrama de clases y de
esa forma voy encontrando casos de uso. Los primeros que voy a encontrar son los esenciales porque
hacen a los principales procesos o a la secuencia de todo el accionar de ese negocio y luego lo voy
completando con todos los casos de uso de soporte que completan la funcionalidad del sistema, a
todo esto, después del diagrama vendrá lo que significa la descripción que se verá más adelante.
Esta tarea consiste en elaborar diagramas y descripciones para explicar el modelo de casos de uso
en totalidad.
El modelo de casos de uso puede organizarse en conjuntos de casos de uso conformando paquetes
de casos de uso. Este concepto de subsistema esta orientado a paquetes, cuando sea muy grande el
diagrama voy a agrupar en paquetes para poder manejar la cantidad de casos de uso y ser manejable
a la vista el diagrama.
Completando el diagrama nosotros vamos a representar a todo lo que vamos identificando, los actores
hacia afuera, los casos de uso hacia dentro, las relaciones entre casos de uso dentro de un recuadro
que lo vamos a llamar limite , la relación entre actor y caso de uso van a ir representándose, cruzando
ese límite y los actores con la generalización entre actores si surge fuera de ese límite.
Al realizar la representación se agrega un recuadro que representa la delimitación o límite del sistema.
La idea es que yo a medida que
voy graficando voy encontrando
actores, uno o muchos, voy
encontrando caso de uso y hago
la representación entre actor y
caso de uso, voy a hacer un
recuadro recordando que
encontrar actores me sirve para
marcar el amiente y lo que
corresponde al sistema, este
límite gráficamente permite esta
identificación. A la vez voy a ir
estableciendo distintos tipos de
relaciones.
Análisis de Sistema Resumen Nicolás Aguirre
Describir casos de uso
Nosotros vamos a partir del diagrama de casos de uso, a cada caso de uso nos vamos a tener que
meter en su interior y vamos a escribir una serie o secuencia de acción. Dijimos que un caso de uso
es un fragmento de funcionalidad, un conjunto de acciones , una secuencia de acciones que tiene un
objetivo, que obtiene un resultado y que le da valor al actor que esta instanciando el caso de uso.
La descripción del caso de uso es meterse dentro de el y describir esa secuencia de acciones, que es
la lógica que sigue ese proceso, siendo lo que vamos a programar con un lenguaje de programación.
De alguna forma iremos encontrando escenarios y pasos, vamos a tener que describir una serie de
elementos básicos que significa una buena descripción de un caso de uso, vamos a ver esos puntos
mínimos que forman parte de una descripción y veremos una plantilla en particular algún formato
donde ordenamos los datos que vamos a describir.
Una descripción de casos de uso lo que tiene que lograr describir claramente y en detalle son esa
secuencia de acciones o los pasos para alcanzar un objetivo, en general una descripción de casos de
uso va a tener una secuencia de pasos. Siempre vamos a tener una secuencia de pasos y cumplimos
un objetivo, pero podríamos tener distintos caminos o flujos en los cuales vamos a también tener que
describir. No solo vamos a describir un camino, el ideal, el que ejecuta todo bien y llega a sus
resultados finales, sino que vamos a tener que pensar como analistas todas esas posibilidades que
esa función podría tener, ir pensando todos los caminos que sean alternativos y lo mismo cumplan el
objetivo y también tendremos que detectar esos caminos que por alguna situación que no logran
cumplir el objetivo.
El esfuerzo de describir el caso de uso es para encontrar todos los caminos posibles, aquellos que
cumplan el objetivo porque si existe el caso de uso existe el camino para que se cumpla el objetivo,
pero no es lo único a describir, sino todos los caminos posibles, los que logran el objetivo y aquellos
que no detectando la situación por la cual no.
De esta forma lo que nosotros vamos a ir encontrando son lo que se llaman escenarios y pasos.
Los escenarios serian cada uno de nuestros flujos o caminos posibles y la secuencia de acciones
serian cada uno de los pasos en esos escenarios , entonces para realizar una descripción de casos
de uso deberemos considerar encontrar y definir escenarios y pasos.
Nosotros vamos a lograr describir en detalle esa lógica del proceso en un lenguaje no técnico porque
eso es lo que viene a posteriori, sino en un lenguaje con una serie de pautas y de criterios y un orden
dentro de esa plantilla, pero con un lenguaje descriptivo, narrativo de lo que nosotros queremos contar
que ejecuta esa secuencia de acciones.
Se realiza una descripción por cada caso de uso identificado en el diagrama de casos de uso. Si
nosotros encontramos una función y hemos dibujado en el diagrama un caso de uso significa que ese
caso de uso tiene una secuencia de acciones. Entonces tenemos un sistema con 80 casos de usos
entre esenciales y de soporte entonces tendremos 80 descripciones que es una por cada caso de uso
porque cada función tiene una lógica de proceso y a futuro tendrá un lenguaje de programación una
codificación utilizada para describir esa lógica, para que ejecute completamente.
Nosotros vamos a tener que partir para poder hacer una descripción de considerar los actores, el caso
de uso no funciona por si mismo si no que vamos a tener interacción con un usuario, cada cosa que
el usuario acceda al sistema vamos a tener que escribir que va a hacer y si ese actor es un dispositivo
de hardware u otro sistema tenemos que ver qué información ingresa y que información le provee.
Análisis de Sistema Resumen Nicolás Aguirre
Los actores y el rol que desempeña me van a servir y vamos a tener que utilizarlo para poder describir
el caso de uso. Los casos de uso tienen actores que desempeñan roles y tienen metas, nosotros
vamos a describir el caso de uso para describir como se ejecutan ese conjunto de acciones y cumple
con el objetivo o la meta del actor. El caso de uso colabora con el cumplimiento de dichas metas.
Nosotros vimos que los acotes se clasifican en primarios y secundarios, aquel actor que inicia el caso
de uso o lo instancia es el actor primario y es el que tiene que el objetivo y debe lograr su meta con la
ejecución de esa función. Siempre que empecemos a describir un caso de uso vamos a tener que
indicar que ese actor inicia esa acción para lograr que cosa, ese es nuestro disparador para saber cual
es la secuencia de acción a la cual nos dirigimos y que es lo que quiere lograr ese actor y en función
de eso vamos a saber que debemos pensar como la lógica del proceso que queremos describir.
Un actor primario quiere lograr una meta, inicia una acción para lograr esa meta e instancia para ello
un caso de uso que va a describir los eventos que puede permitirle a algún actor alcanzar su meta.
Esos eventos van a conformar el o los diferentes caminos que dicho actor puede seguir para alcanzar
dicha meta, se dicen el o los porque hay distintos flujos teniendo una secuencia de acciones logrando
el objetivo, pero también puedo tener algún otro camino que también ejecuta algunas acciones en
común y otras diferentes, pero también logra el objetivo. Por otro lado, tendremos la detección de esas
situaciones donde no logra el objetivo que también vamos a tener que describir en qué situación ocurre
donde se interrumpe el proceso, no se logra cumplir con el objetivo, pero también tiene que quedar
descripto todos los posibles caminos.
Cada uno de esos caminos lo vamos a llamar escenarios, cada posible camino de la ruta que vamos
a tener y de cada escenario que vamos a identificar al menos siempre vamos a encontrar una
secuencia de acciones que cumpla el objetivo y vamos a lograr un resultado. Ese concepto de un
escenario que finalice cumpliendo el objetivo es lo que denominamos un escenario por un camino que
finaliza en éxito, que logra cumplir el objetivo.
Cada escenario representa un camino claro a través del sistema, comprendiendo un conjunto de
acciones. Lo que siempre al menos por cada caso de uso vamos a encontrar es un escenario que
finaliza con éxito y cumplen el objetivo , pero no debemos quedarnos solo con eso, debemos identificar
todos los otros escenarios que lo mismo ejecuten la secuencia de acciones y si finalizan con éxitos
vamos a encontrar uno o varios términos o logros de esos escenarios con éxito. Por otro lado, aquellos
que interrumpen el proceso, que no logran cumplir con el objetivo también lo vamos a describir y
significan escenarios que finalizan en fracaso, esos eventos quieren decir que la secuencia de
acciones no cumple con el objetivo y le impiden al actor alcanzar su meta. Una descripción debe
contemplar todos esos escenarios.
El conjunto de escenarios que vamos a tener nos va a ir definiendo distintos caminos o también se los
llama los cursos, curso normal o principal y cursos alternativos. El curso normal o principal van a ser
esa secuencia de acciones que cumplan con el objetivo del caso de uso y los cursos alternativos van
a ser todo el conjunto de caminos o escenarios posibles ya sea que logren con éxito o que sea en
fracaso y lo vamos a tener que describir y la plantilla va a tener una forma en la cual en un espacio se
va a escribir ese curso normal o principal y en otor espacio de esa plantilla se va a escribir esos cursos
alternativos ya sean que también terminen con éxito o también sea su finalización en fracaso.
El caso de uso es contar una historia y nosotros vamos a contar tantas historias como ese caso de
uso tenga según todos los caminos y esa ruta que vayamos contando. Esas historias que vamos a ir
contando se van a contar por pasos, tendremos aquel camino o curso normal va a estar normalmente
definido como esa secuencia de pasos que ejecutan sus acciones y logran una finalización del caso
Análisis de Sistema Resumen Nicolás Aguirre
de uso con éxito. Siempre todo caso de uso tiene su curso normal y logra con éxito ese objetivo finaliza
con éxito.
Pero no es la única opción, nosotros podemos ir teniendo rutas alternativas, si paso esto ocurra una
cosa o tal otra. Por ejemplo, si estoy registrando la venta de un producto, primero ingreso y busco los
datos del cliente, luego busco el producto a ver si hay stock continuando o no según haya, luego
genero el importe total que dependerá de si quiere pagar con contado seguiré un camino y si quiere
pagar con tarjeta seguiré otro camino porque hay que buscar autorización, obtener el cupón y demás.
Estas son las rutas que van surgiendo a un camino o curso normal.
Vamos a tener que detectarlas y describirlas a todas. Aquella historia que cubra y cumpla con éxito el
objetivo es un curso normal o curso alternativo con éxito y aquel que interrumpa o que no pueda cumplir
porque alguna condición se da en la cual no cumple con el objetivo también será cursos alternativos
que terminan con fracaso.
Las piezas de un caso de uso
Cuando nosotros vayamos a describir cada escenario deberemos considerar pasos y esos pasos
tienen estos criterios, cada paso tiene que ser significativo y que el actor o el usuario que esta
instanciado ese caso de uso logre avanzar en algo ese paso tiene que ser significativo y que logre un
resultado para que hagamos una siguiente acción. Cada paso hace avanzar al actor hacia su meta y
cada paso describe alguna acción significativa a lo largo del camino, en esa cantidad de pasos vamos
encontrando condiciones alternativas y de error, con validaciones necesarias.
Debemos considerar la lógica de este proceso en donde debemos considerar que si hago este paso
analizar si siempre va a ejecutar y el resultado es positivo o si una situación extra puede ocurrir y ahí
empezamos a encontrar distintas condiciones que validar y distintos escenarios alternativos.
El principio de la descripción
Siempre que van a iniciar la descripción de un caso de uso, deben pensar:
El estado inicial significa que empieza el caso de uso, que situación previa al inicio del caso de uso
debe estar dada en el sistema para que ese caso de uso pueda iniciar, ese concepto que se llama
estado inicial es lo que vamos a denominar en la plantilla como la precondición. Siempre que
empecemos a pensar un caso de uso, debemos pensar que si este caso de uso se tiene que iniciar
que situación tiene que estar dada para que este caso de uso pueda iniciar.
Además, al principio de la descripción de un caso de uso vamos a tener que indicar quien inicia el caso
de uso, que para que lo esta iniciando y cuando lo inicia. Vamos a tener una redacción de una primera
oración que podría ser algo como: “el caso de uso comienza cuando el actor que tenemos desea …”
En este momento estamos indiciando quien, que y cuando. Cuando quiere registrar los datos de un
cliente cuando tenga datos nuevos a registrar, ese es el cuándo, no habla de un tiepo fijo, por tirar un
ejemplo.
Otra forma de redactar esto sería: “El responsable de ventas ingresa a la opción para registrar los
datos de un cliente”: Recordemos que a futuro un caso de uso va a tener lógica de programación,
codificación y pantalla, todo lo que estamos describiendo van a ser acciones de un sistema y con
interacción de un usuario, de un actor que hace acciones en el sistema. Su descripción debe tener la
forma, el lenguaje narrativo que vamos a usar siempre expresando acciones que un actor ejecuta,
realiza en relación con un sistema. Cualquier acción que un actor ingrese datos a un sistema o por lo
Análisis de Sistema Resumen Nicolás Aguirre
cual inicia una acción cuando yo entro al menú de opciones de cualquier acción, inicio algo, doy
comienzo de esa funcionalidad.
Ese es mi disparador, yo tengo un actor que inicia una función y la describo en mi primera oración.
Un ejemplo para poder explicar precondición seria decir que nosotros para poder registrar la inscripción
de la materia tuvimos que logearnos y para poder ejecutar esta acción que significa que yo como
alumno que ya estoy registrado y soy usuario quiero registrarme en una materia la precondición de
este caso de uso es que ya ese alumno inicio sesión y es un usuario del sistema. Eso es la
precondición, algo que debe estar dado para que pueda iniciar el caso de uso.
El desarrollo de la descripción
Toda la secuencia de acciones que nosotros vamos a describir de ese caso de uso va a tener un
orden, todo tiene una secuencia lógica, entonces los pasos los vamos a ordenar según la secuencia
lógica de ocurrencia, entonces las acciones necesarias y el orden requerido en que las acciones se
deben ejecutar. Vamos a ir enumerando esos pasos que normalmente según cada plantilla pueden
jugar distintas formas de descripción y distintas formas de numeración.
Vamos a tener que encontrar toda la secuencia de acciones y las vamos describiendo con el orden
lógico de secuencia y las vamos a ir enumerando.
Cuando yo vaya describiendo los pasos la idea es que vamos a tener distintos pasos diferenciando o
distinguiendo lo que hace el actor de lo que hace el sistema. El actor ingresa algo por teclado, el
sistema en función de ese ingreso hará algo, esas acciones se deben diferenciar en distintos pasos,
lo que hace el actor de lo que hace el sistema.
El desarrollo es una secuencia de acciones en un orden lógico, cada una de esas acciones se llaman
pasos y a cada paso lo vamos a enumerar y a la vez vamos a tener que ir diferenciando en distintos
pasos acciones que hace el actor de acciones que hace el sistema.
Vamos a tener que describir en detalle los datos y toda la información que va a ir manejando ese caso
de uso, los datos que se muestran se detallan con cada uno de los datos, los datos que se registran
también se van a detallar, así como los datos que se consulta, actualicen, modifiquen, eliminen, cada
dato debe estar detallado porque da a describir la lógica del proceso, tengo que ser especifico
indicando que ingreso tipo, número de documento, apellido, etc. Si yo dejo una oración en el paso
donde digo ingresa datos del cliente no estoy siendo detallista porque no digo de que datos. La
descripción tiene que tener en detalle los datos de la acción que estemos describiendo, cada paso
tiene una acción y hace una manipulación con los datos. Se debe describir cada dato.
El caso de uso cuando describa la función que se relaciona con el comportamiento de la clase del
diagrama de clases debo tener coherencia con los datos de esa clase. Si la clase cliente tiene 10
atributos cuando yo muestro datos del cliente solo puedo mostrar datos que la clase contenga, sino
tengo una incongruencia porque no tengo de donde obtenerlo.
Yo describo casos de uso que es la lógica de como ejecuta el conjunto de acciones ese sistema y a la
vez todos los datos que manipule, toda la información que maneje debe ser congruente con un
diagrama de clases que esta teniendo en esas clases los atributos y el comportamiento del sistema y
de esa forma estoy creando dos diagramas que tienen correspondencia y una descripción que
acompaña a ese diagrama de clases.
Análisis de Sistema Resumen Nicolás Aguirre
Entonces si van viendo la descripción de casos de uso es un trabajo que demanda esfuerzo porque
hay que tener congruencia, yo pienso la lógica que va a tener por detrás el sistema antes de meterme
en la programación.
Cuando yo tengo una descripción de un caso de uso base,
acá hay dos casos de uso que tiene una relación de
extensión, que era aquello donde yo estoy en un caso de uso
base y en función de una secuencia de pasos que voy
ejecutando en algún momento según cierta condición puede
ser necesario que llame a otro caso de uso que ejecute otro
caso de uso, siempre es a partir de una situación alternativa
de un control de alguna condición.
De esta forma vamos a tener un caso de uso base que vamos
a tener que describirlo y un caso de uso extendido, que a la
vez también es un caso concreto porque tiene instanciación directa y también tendremos que
describirlo.
Cuando yo estoy describiendo un caso de uso base tendré que describir de forma clara en que
secuencia de acciones se hace variación o ese control de condición o esa llamada al otro caso de uso
y que ocurre al retornar porque justamente esa es la secuencia. Piensen en un programa, yo estoy en
una acción de un sistema y ejecuto bajo cierta condición otra función y me voy a otra funcionalidad a
otra lógica del programa, cuando vuelvo tengo que saber que ocurre. Eso es lo que es a nivel de
descripción hay que hacer, debemos lograr esa abstracción previa antes de meterse a codificar deben
meterse a pensar la lógica.
Cuando un caso de uso base tenga que llamar a otro por inclusión o extensión debemos tener la
secuencia de pasos que describan claramente este concepto, eso es lo que dice este párrafo. En la
descripción se indican como pasos las llamadas a otros casos de uso indicando claramente estas
llamadas a dichos casos de uso ya sea de inclusión o de extensión. Siempre pasa para las llamadas
de inclusión o de extensión y desde el caso de uso base. Esto se describe en el caso de uso base, en
el paso donde en se debe realizar la llamada a los casos de uso de inclusión y/o extensión según
corresponda en la secuencia necesaria.

El paso 3 significa que cuando estamos haciendo registrar solicitud de turno yo buque si el paciente
existe o no, si no se encuentra debo llamar y ejecutar esta extensión a un nuevo paciente, eso en un
sistema sería un botón que tengamos de registrar nuevo paciente. En los pasos se debe diferenciar lo
que haga el actor de lo que haga el sistema en distintos pasos, una llamada a otro caso de uso de
inclusión o de extensión al menos tiene dos pasos, uno donde el actor hace la llamada al caso de uso
y otro donde el sistema llama al caso de uso registrar paciente para registrar sus datos personales,
Análisis de Sistema Resumen Nicolás Aguirre
dependerá del caso de uso base que van describiendo al menos un paso donde el sistema llama al
caso de uso o dos pasos entre una acción del actor y otra del sistema.
Al final de la descripción de un caso de uso
Mínimamente tenemos que indicar como y cuando terminan los casos de uso, van a haber uno o mas
pasos en donde indiquemos como finaliza el caso de uso y al menos vamos a tener un paso ultimo
que hable en la descripción que sea que cumpla con el objetivo, si el objetivo era registrar los datos
de un cliente, tener todos los pasos donde voy registrando hacer validaciones lo que fuera y al final un
paso donde el sistema registra los datos de un nuevo cliente. Debe haber un paso que cuando yo lo
lea este cumpliendo con el objetivo del caso de uso y seria ese escenario que finaliza con éxito, pero
no sería el único parte final o descripción final, vamos a tener que considerar todos los escenarios
alternativos que también terminaron por éxitos o fracaso con las rutas alternativas que fuimos
encontrando y describiendo.
Por cada caso de uso el o los caminos que hemos detectado, los escenarios, debemos indicar la
finalización de cada uno. Indicando en la descripción la finalización del caso de uso y si existen posibles
interrupciones o cancelaciones del mismo.
Cuando empiezo una descripción de un caso de uso
analizo si hay precondiciones, a veces puede haber
y a veces no, precondición es un dato alternativo,
pero hay que pensarlo si tiene o no. Luego siempre
se le sugiere describan el curso normal hasta llegar
al objetivo que seria el curso de éxito, ejecuto una
serie de pasos y al menos cumplo con esa
secuencia de pasos, el objetivo principal. Y después
voy a tener rutas alternativas que pueden ser
alternativas y vuelven al camino, pueden ir
terminando con flujo alternativo y ser interrumpidas,
esos van a ser los distintos éxitos y fracasos del
mismo caso de uso.
Vamos a tener que considerar las post condiciones que son todos los resultados posibles de un caso
de uso considerando los éxitos y los fracasos, el éxito es el resultado que cumple con el objetivo del
caso de uso y el fracaso es cada interrupción o cancelación y que no cumplen con el objetivo de dicho
caso de uso. Con esto vamos teniendo todas las consideraciones mínimas que un caso de uso debe
tener.
Cada vez que deban describir un caso de uso debemos considerar todas las instancias de inicio
desarrollo y final que hemos visto.
Otras consideraciones que debemos tener es que cada vez que nosotros describamos un caso de uso
vamos a describir una plantilla y hacer el diseño de prototipo de interfaz, es importante que cuando
escribamos esos pasos en el caos de uso no hagamos referencias a recursos de implementación a
elementos de la pantalla, deben ser elementos con cierta abstracción de los elementos concretos que
vayan en el dibujo de esa ventana.
Por ejemplo, no corresponde indicar “presiona el botón guardar” hoy el botón se llama guardar,
después se llama aceptar y después lo reemplace con un icono. No debemos hacer una descripción
pegada al diseño, debemos describirlo de forma mas abstracta, por ejemplo: “el responsable de ventas
Análisis de Sistema Resumen Nicolás Aguirre
acepta o confirma el registro de los datos del cliente”. No importa como varie el botón, de esa forma
tendremos que describir todo.
Otro error, es decir: “despliega la grilla” “hace click en el check” Eso es hablar de los recursos de la
interfaz, una descripción no debe mencionarla, debe estar hecha en un punto de abstracción
independiente de cómo se implementa así se mantiene en el tiempo esa descripción. A mi me interesa
el paso de que el actor confirme la acción, no me interesa el elemento visual que yo puntualmente en
un inicio lo llame de una forma y después lo quiero cambiar. Es más fácil de mantener esa descripción,
sino pensemos: yo tengo un diagrama de casos de uso de 100 casos de uso, si yo describo los cien
con los elementos de implementación y supóngase que 50 de ellos usen la acción guardar, y después
por una cuestión del diseño le pongo en vez de guardar, aceptar, tendría que modificar 50 casos de
uso cambiándole la palabra donde no cambia ni la lógica y el caso de uso sigue funcionando. Eso es
lo que busca esta consideración.
Otra consideración es que cada dato que vayamos describiendo en cada paso debe tener una
correspondencia, para que el diagrama y la descripción sean consistente con el modelo de objetos
dominio del problema (Diagrama de clase).
Integración de modelos
Nosotros hemos ido viendo que modelamos el negocio con el mapa de procesos, descripción de
procesos, el objetivo del sistema de información, requerimiento funcionales y no funcionales, hemos
hecho un modelo de dominio en correspondencia con el negocio, el objetivo y el listado de
requerimientos y estamos aprendiendo, diseñando y modelando todo lo que tenga que ver con casos
de uso, siendo una correspondencia con cada uno de los modelos, el de negocio me va a dar todo lo
que debemos considerar, encontrado actores en función de los carriles y los recursos humanos, el
objetivo del sistema de información para saber hacia donde vamos, los requerimientos funcionales
para saber los caos de uso, con los no funcionales es la consideración del entorno y lo que debimos
haber tenido en cuenta de no funcional y luego voy creando y construyendo, encontrando casos de
uso, actores y relaciones y voy construyendo un diagrama de casos de uso en correspondencia con
todo un modelo del dominio también voy describiendo los casos de uso con todo lo visto.
Un sistema para que este bien hecho, sea consistente y este integrado va llevando todos estos
caminos que vamos viendo y va teniendo una coherencia, si yo digo que acá existe una función en el
sistema es porque tiene sustento del modelado de negocio, de requerimientos y del modelo del dominio
que indica que esa función del sistema se ejecuta bajo qué condiciones.
Análisis de Sistema Resumen Nicolás Aguirre
Que es un prototipo
El concepto de prototipo en si es un concepto que se usa en distintas áreas, siempre tiene una
intención o un fin que hace una representación limitada de un producto, la idea es que eso sirva a
modo de prueba para poder explorar la situación como esta en función del diseño y del área de trabajo
lo que uno quiere verificar, trabajar o probar.
Los prototipos son una representación limitada de un producto, permiten a las partes probarlos en
situaciones reales o explorar su uso y un prototipo puede ser desde un sencillo dibujo en un trozo de
papel a un complejo software.
En el caso nuestro que vamos haciendo para lo que es sistema, lo que vamos a hacer son prototipos
de interfaz, son diseños de ventanas, eso es lo que nos va a servir en este proceso de ingeniería de
requerimientos una vez diseñado poder trabajar con ese futuro cliente y poder validarlo para saber si
estamos entendiendo lo que necesita o no.
En función de eso es lo que nos va a servir a nosotros hacer prototipos, vamos a hacer sobre las
ventanas o pantallas que tendrá el sistema en correspondencia con los casos de uso y me va a servir
luego para validar con el cliente si estamos encaminados o no. Y esto que dice que puede ser un trozo
de papel o un complejo software, en un inicio cuando empiece el sistema a veces son bosquejos a
mano o hechos con alguna herramienta, pero solamente tienen la cara dibujada o a veces podemos ir
haciendo los prototipos de interfaz con un lenguaje de programación o con algún software que tenga
algo de interacción cada uno de esos elementos del prototipo.
Que es una interfaz de usuario
Los prototipos de interfaz de usuario se los escribe como IU, justamente al cliente no le vamos a
mostrar el código o el diagrama de clases, al cliente le vamos a mostrar lo que el visualmente va a
tener luego para el uso del sistema van a ser la cara del sistema, es desde allí que la interfaz de
usuario es la cara de la pantalla que nosotros vamos a diseñar y es la que me va a permitir la
comunicación con ese futuro usuario y con el cliente y es la forma en la que el usuario va a interactuar
justamente con el software o la computadora.
Ese prototipo en general va a estar diseñado utilizando todo el lenguaje que ese negocio y cliente
utilizan, usa un lenguaje natural con el uso de la tecnología que nos va a permitir justamente a la parte
nuestra la codificación que por detrás tiene esa pantalla.
El concepto y el diseño propiamente viene de fines de los 70s es cuando aparece este primer concepto
de interfaz grafica de usuario, antes todo era con sistemas operativos y con software que era con
sistemas operativos de base, no tenia nada de diseño gráfico. Fue apareciendo a partir de la empresa
Xerox que diseño la primera interfaz y fue a mediado de los 80s cuando Apple hizo popular estas
interfaces, siendo luego copiadas por Microsoft con sus Windows.
En un software bien diseñado, los elementos que componen la interfaz son funcionalmente
independientes y están conectadas de forma indirecta al programa.
Que es el diseño de interfaz de usuario o interfaz grafica de usuario (GUI)
Nosotros vamos a ir diseñando interfaces y vamos a tener que tener en cuenta una serie de principios
o buenos criterios para esa interfaz graifca de usuario sea útil y le sirva justamente al cliente. Entonces,
hago un esfuerzo en este diseo que uno va diseñando que mientras uno va pensando el caso de uso
y la secuenic alogic tiene que ir pensando la mejor forma que tenga esa ventana de tla forma que sea
Análisis de Sistema Resumen Nicolás Aguirre
de fácil uso para ese usuario. Es por eso que hay una serie de principios que tenemos que considerar
para que pueda ser útil.
Están los principios agrupados en estos 6 aspectos básicos de estos principios pero hace a todo un
buen diseño de una interfaz. Estos principios buscan que logremos nosotros aparte de pensar
funciones, crear una estructura solida contundente como el modelo de objetos y de casos de uso que
sepamos hacer interfaz que es lo que va a usar el usuario, porque si por detrás el sistema maneja la
complejidad de forma exacta, es barbaro, pero la vista que tiene el usuario es rudimentaria, no es
conisstente, es poco intuituiva ese usuario no usa el sistema y ahí perdimos nosotros. Enotnces hay
todo un trabajo en lo que es este diseño de interfaz.

Familiaridad del usuario: es que nosotros usemos términos y conceptos que sean del vocabulario de
ese negocio, eso lo vamos a ir descubriendo en una elicitación y en un trabajo de conocimiento de ese
negocio y en el modelo de negocio para que usemos esos términos correctos. Si estamos hablando
de un hospital cuando hablemos de las personas que pidan un turno serán pacientes, no decimos
cliente y si estamos modelando una parte de hotelería o una venta de pasajes la persona no la
llamamos cliente sino pasajero.
Consistencia: la idea es que todo sistema que hagamos y que use la interfaz sea consistente con las
operaciones que por detrás van. Nosotros vamos a describir casos de uso, pero lo que va a ver el
cliente es una interfaz con el vocabulario y que las operaciones que va haciendo sea consistente
conforme las distintas pantallas va ejecutando. Yo voy a registrar un cliente y tengo los botones de
aceptar y cancelar, en la otra pantalla de pedido tengo el botón aceptar y cancelar como iconos allá
arriba y en una tercera pantalla que registro productos a vender tengo los iconos en la parte lateral
izquierda. Eso no es consistente yo lo desoriento al usuario porque le voy poniendo botones con el
mismo concepto de acción con distintos iconos, colores, nombres, lo que tenemos que buscar es una
consistencia entre los distintos elementos y la forma en la que trabaja sistema se comporte semejante
en las distintas funciones que va ejecutando.
Análisis de Sistema Resumen Nicolás Aguirre
Mínima sorpresa: es la idea de que sea intuitivo, a medida que va ejecutando funciones el usuario no
tenga situaciones que no sepa que hace el sistema, no tiene mensajes, no lo orienta, toca un botón cri
cri, nada, la pantalla no muestra nada, no le dice que esta en progreso, que esta ejecutando, que se
canceló, etc. Ese es el criterio de mínima sorpresa, disminuir esa situación en donde el usuario no
sepa que esta pasando con el sistema.
Recuperabilidad: hay acciones en algunos sistemas con funciones muy importantes que ejecutan algo
y que tal vez cometió un error grave, entonces algunas acciones permitirle lo que se llama un rollback,
un volver atrás, un recuperarse de errores, dependerá de situaciones bien concretas en algunos
sistemas en el cual nosotros le permitamos alguna anulación o alguna acción que destruyo o elimino
algún dato importante, alguna transacción, como podrían recuperar o hacer una auditoria o
seguimiento de esa información que acaba de eliminar por ejemplo.
Guía al usuario: este tema de cuando van ocurriendo errores que los mensajes sean claros y
significativos de que es lo que ocurrió que hizo mal o que hizo bien en función de también agregarle
las ayudas al sistema que el usuario tenga una explicación del uso del mismo y ante un mensaje de
indicación de un error el entienda en que consistió ese error.
Diversidad de usuarios: no todo diseño siempre es igual, sino que nosotros tenemos un modelo de
negocio, personas reales que van a interactuar con el sistema y tienen características. Depende del
proyecto, el ámbito donde va a ser aplicado y el usuario a futuro que lo va a utilizar va a depender del
diseño que vamos a hacer, tenemos esa consideración, el contexto real, los distintos usuarios que lo
van a utilizar.
Estos principios son importantes y tienen que ver con que logremos un buen diseño
¿Por qué es importante el diseño de interfaces de usuario?
Como la interfaz es la cara del sistema y es la interacción que el usuario va a tener tiene que estar
bien diseñada, atendiendo todos esos principios que acabamos de ver. Es la única forma en que el
usuario entienda el sistema y aparte es lógico, no tiene por qué conocer toda la parte técnica que por
detrás tiene esto, entonces hay que considerar todos los principios porque un usuario que no le gusta
la interfaz haga mal uso del sistema, el sistema va al fracaso por tanto es importante una buena
interfaz.
Hay que tener en cuenta las habilidades humanas, capacidades físicas y mentales de las personas
que utilizaran el software entiendo ben estas capacidades físicas y mentales sin discriminar.
La idea es que a veces nos toca desarrollar sistemas en donde una funcionalidad tiene como muchas
pantallas asociadas y a la vez esa acción que va haciendo ese usuario si tiene que usar mucho la
memoria o una secuencia lógica en su cabeza de como usar ese sistema y el sistema no lo guía, no
tiene mensajes de ayuda no es intuitivo, termina a la larga la persona no haciendo un buen uso del
sistema, no siendo útil y fracasando el mismo.
Presentación de la información al usuario
Nosotros cada vez que vayamos pensando el diseño de una pantalla se pueden encontrar con una
multiplicidad de elementos a incluir o formatos que deben dar a su diseño, todo dependerá de la
realidad, de la creatividad de nosotros, la atención al sistema real y la consideración del usuario real.
En estas primeras practicas tendremos solo un enunciado, pero en la realidad uno tiene un contacto
con esa variedad de usuarios y eso mas requerimientos no funcionales que nos van contando,
aspectos visuales que les gustaría y que no y de esa forma uno va empezando a diseñar estas
Análisis de Sistema Resumen Nicolás Aguirre
interfaces. Nos puede llegar a tocar diseñar multiplicidad de pantallas, algunas que sean como mucho
texto, con grillas o campos de ingreso y una cantidad de datos o con gráficos que eso será cuando
tengamos que generar resúmenes, cuadros de control o de mando que significa graficas estadísticas
y a partir de allí por detrás detalles de información. Tendremos que ir teniendo en cuenta en los distintos
diseños según el caso real.
Uso del color en el diseño de la interfaz
Hay que hacer y aprender a jugar con el color y con la variedad o paletas de colores en un sistema.
Normalmente todo negocio cuando vamos desarrollando un sistema suele tener sus logos de la
empresa o tiene una gama de colores que trabaja, nosotros tenemos que tratar de trabajar con un
sistema que lleve esa misma línea de trabajo. A veces ese menú principal tiene que tener los logos,
depende el tipo de empresa y requerimientos funcionales nos indiquen y tal vez en los primeros
prototipos si es en papel vamos solamente a los datos, pero hay prototipos que uno le va mostrando
al cliente que va jugando con la gama de colores, con distintos usos de como va quedando el mismo
y el cliente nos va orientando.
La idea es usar una cantidad de colores acorde a la línea de trabajo de la empresa y por otro lado no
usar colores fuertes, no usar contrastes fuertes, no usar una gran cantidad de colores, ser medibles
en limitar la cantidad de distintos colores utilizados y a la vez en funciones de los colores que utilicemos
combinar tal vez un par de colores manejándome en la gama y que hayan botones que refieran a una
misma acción con un mismo tono y dejar el rojo o colores fuertes para algunos mensajes de error que
destacan, etc.
Hay sistemas que se utilizan muchas horas al día, si el color es muy fuerte o tiene muchos contrastes
de colores, esa vista de esa persona y el uso del sistema termina en las ultimas horas con un cansancio
visual, todo eso tiene que irse viendo y si queremos un mensaje de error que esa tenga un color que
destaque y el resto de tonos que vaya logrando una paleta de colores tranquila y de poca variedad.
Análisis de Sistema Resumen Nicolás Aguirre
Elementos de una interfaz gráfica de usuario
En un inicio vamos a tener por cada caso de uso una pantalla con funcionalidad concreta pero a la
larga tenemos que diseñar todo, los menus, las opciones, y las llamadas a las funcionalidades
concretas. El menú viene en distintos formatos.
Esa opción de nuevo significa registrar nuevo cliente,
nuestros casos de uso van a estar y la descripción del
caso de uso y el prototipo inicial que estamos haciendo
estamos hablando de esta funcionalidad que ya viene
de un requerimiento funcional que era registrar cliente.
Esta opción de facturar en un menú va a estar asociado
a un caso de uso que será generar factura de venta o
registrar pedido de venta y ese es el caso de uso que
va a estar asociada a este nombre en un menú y
nosotros aprendemos que en un diagrama de casos de
uso esta dibujado, tiene una descripción y tiene una pantalla o un conjunto de pantallas en función de
la cantidad de datos que manden.
Un menú a la larga se hace mas bien una vez que uno va avanzando con las primeras funciones
cuando va agrupando como va a unir esas funciones en el sistema y las opciones principales.
Eso es por un lado, por otro lado cuando vayamos diseñando cada pantalla tenemos que saber
diseñar, hay ventanas para lo que es cargad e datos, ventanas para mostrar datos a partir de una
consulta, ventanas que hacen procesos, cálculos y demás.

Cuando desplegamos se llama combo, cuando agrupo datos es un panel o frame, el desplegable se
conoce como lista despegable, a cada nombre que le damos en cada campito es etiqueta/rotulo/label,
después todos los iconos para administrar el tamaño de pantalla. Toda ventana debe tener un titulo,
cuando ingresamos un dato hay cajas de texto, toda pantalla va a tener botones que tenga el nombre
o que sean gráficos.
Análisis de Sistema Resumen Nicolás Aguirre

Podemos usar calendarios para selección de fechas, campos memo que son bloque de teto para
ingresar, una múltiple variedad de iconos, hay iconos web que a veces se diferencian de otros iconos,
los tooltips son distintos mensajes que cuando uno se para sobre un campo le tira un mensaje dando
indicaciones.
Análisis de Sistema Resumen Nicolás Aguirre
Análisis de Sistema Resumen Nicolás Aguirre
En los entornos mobile cambia el diseño porque sabemos que el espacio, la disponibilidad y los
recursos son diferentes, entonces tenemos que considerar que siempre debe respetarse lo que puede
entrar en la aplicación mobile. Siempre lo mobile usa poco texto, mucho mas visual y como tiene poco
espacio no son para carga de datos, hay una usabilidad diferente.
También va a tener que pensarse que hay diseños de sistemas en entornos web que pueden ser
accedidos desde algunos dispositivos móviles, entonces hay que hacer diseños que se llaman Web
Responsive que significa que lo mismo que veo en la computadora tiene que poder adaptarse a los
distintos dispositivos móviles y ciertos espacios diferentes, esas cosas las debo tener en cuenta.
Nos puede tocar diseño de interfaces táctiles, donde hay veces que pongo una parte del sistema
funcionando en computadoras de forma táctil, entonces los botones que tengo que tocar con el dedo
deben tener espacio suficiente para que se pueda seleccionar.

Relación y consistencia de prototipos de interfaz de usuario y el resto de lo modelado

El prototipo de interfaz y la descripción del caso de uso van de la mano, son consistentes, son
absolutamente como una sola cosa cuando hablemos de descripción de caso de uso es porque lleva
al prototipo y cuando es prototipo es porque tiene asociado una descripción.

Tendré tantos prototipos de interfaz como casos de uso que describimos, a veces podemos tener en
función de la complejidad de caso de uso tal vez el caso de uso tiene una o varias pantallas o a veces
dos o tres casos de uso pueden estar diseñadas en una misma pantalla o a veces un caso de uso o
un prototipo. Por ejemplo, registrar una venta cuando describe el caso de uso normalmente tiene un
prototipo de interfaz que son los datos de la venta y se puede diseñar el núcleo.
Cuando un caso de uso tenga mas de un prototipo de interfaz, por ejemplo cuando estoy registrando
un paciente con toda su historia clínica, yo tendré distintas solapas, en una datos personales, en otras
Análisis de Sistema Resumen Nicolás Aguirre
antecedentes médicos y en otra información de las consultas, entonces vamos teniendo distintos
prototipos pero asociados a la misma funcionalidad.
Dos o mas casos de uso, el ABMC que son el alta, la baja, la modificación y la consulta se maneja en
un solo prototipo con distintos botones, si quiero modificar lo busco, los muestra , edito los datos para
que los modifique, si quiero eliminar me muestra los datos y puedo dar de baja. Ahí vamos a tener
asociado un mismo prototipo con distintas funciones, por ejemplo.
Eventualmente un caso de uso puede no tener un prototipo de interfaz asociado, es un caso muy
especial, por ejemplo, tenemos un caso de uso de inclusión que lo sacamos de dos casos de uso base
y es un calculo complejo, pero es un caculo y una vez que ejecuta el calculo devuelve una respuesta
a un caso de uso base. Ese caso de uso que es abstracto que es para un calculo es un caso de uso
que no va a tener ventanas porque el resultado lo devuelve al caso de uso base y cada caso de uso
base le da tratamiento y lo mostrara en su interfaz.
Utilización apropiada de los recursos de diseño de interfaz, como grillas, listas desplegables para
mostrar conjunto de datos o ítems, botones, iconos, campos simples para datos únicos. Debemos
considerar toda la consistencia de lo que describimos con los elementos y los recursos de
implementación utilizados en ese diseño,

Finalmente, esa correspondencia en forma gráfica, estamos dentro de la especificación y todo lo que
forma parte de la especificación, voy construyendo diagrama de casos de uso por cada caso de uso
hago su descripción y hago el diseño de prototipo de interfaz o los y todo lo que describa y todo lo que
visualice tiene una correspondencia directa con el conjunto de clases y con los atributos de cada clase
que yo digo que datos y voy mostrando en esa pantalla y la descripción de la lógica de proceso también
se corresponde con el comportamiento que yo estoy diciendo de las clases y de esa forma voy creando
toda una especificación de requerimientos de software que va a ir a parar a ese documento de la ERS
teniendo una consistencia integral entre modelo de casos de uso y modelo de objetos.
Patrones de casos de uso
Nosotros en la realidad cuando vamos a describir los casos de uso presentan una serie de dificultades
o elementos que tienen que estar bien definidos para que ese caso de uso sirva en su descripción a
la definición de la propuesta del sistema. Generalmente trabajamos en equipo desarrollando todo esto,
normalmente cada uno tiene una forma de escritura, distintos estilos, una estructura mental que le
Análisis de Sistema Resumen Nicolás Aguirre
favorecen y a la vez otro aplica otra y también es un buen resultado, pero cuando nosotros describimos
dentro de un mismo proyecto esos casos de uso tenemos que alinear la forma de trabajar, definir
pautas y acuerdos para que el estilo de la escritura y el detalle suficiente y una buena definición
también sean consistente entre todos los miembros que forman el equipo y trabajan en el mismo
proyecto.
Ese es el disparador o puntapié para ver que nos puede servir para organizarnos mejor , apara unificar
criterios y de ahí surgen lo que se llaman patrones de casos de uso con una propuesta de que podemos
hacer.
Existe una dificultad al describir casos de uso efectivos. Normalmente esta escrito por diferentes
profesionales con diferentes estilos y técnicas. A veces hay dificultades en cuanto al tamaño ya que
ningún tamaño es apropiado para describir todos los procesos, depende de los estilos, del proyecto
particular y una definición que se acuerda de cómo puede hacer el equipo para lograr una descripción
a cierto nivel de detalle que sea suficiente para lo que estamos buscando en ese proyecto. Es de allí
que se necesita un mecanismo que capture esas buenas practicas de escritura y que entonces el
equipo aproveche eso y surgen los patrones de casos de uso.
Los patrones han surgido de esta forma: debido a realizar la tarea uno va aprendiendo que cosas
resultan buenas y que no, entonces de a partir de allí se va teniendo patrones, estereotipos, modelos,
una línea diciendo: “ante esta situación es conveniente desarrollar esto de esta forma”, y a partir de
eso se comulgo a partir de una serie de profesionales que configuraron una serie de definiciones y
construyeron este concepto de patrones para los casos de uso.
Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, así como la solución
a ese problema, de tal modo que se puede aplicar esta solución un millón de veces, sin hacer lo mismo
dos veces. Si es el mismo problema no tengo que pensar como lo resuelvo si ya tengo patrones que
ya me dicen como resolver el mismo.
Un patrón soluciona un problema dentro de un contexto, captura la esencia de una solución que ha
sido probada varias veces en diferentes maneras y en diferentes lugares. Siempre el patron me va a
dar la sugerencia, como analista tengo que ver si esa solución en ese proyecto real y en ese caso en
particular realmente es posible de aplicarse y sino tomo alguna parte de esa solución y sino tengo que
hacer una nueva solución si es muy particular el problema que estoy teniendo que atender en ese
proyecto real, en ese sistema propuesto real.
Por otro lado, proveen un vocabulario, un vocabulario de estas pautas y estas soluciones para poder
realizar igual que el diagrama de clases, las clases son participantes que van proveyendo un
vocabulario igual en casos de uso y en todo lo que vayamos viendo, le va dando una terminología de
esa situación capturada y de esa solución.
¿Por qué usar patrones de casos de uso?
Los patrones de casos de uso describen una serie de aspectos que nos van a ayudar a lograr una
descripción con calidad o construir un diagrama de casos de uso que tengan los estándares de calidad
que significa un buen diagrama completo y consistente.
Los patrones en este lenguaje describen signos de calidad acerca de los casos de uso y del proceso
de escritura de los mismos. Dentro de todos los propósitos que buscamos por un lado nos va a dar
una serie de términos, un vocabulario en la descripción de casos de uso es una ayuda muy importante
en que el equipo que va a trabajar en los escritores de casos de uso para poder definir y alinear los
Análisis de Sistema Resumen Nicolás Aguirre
estilos de escritura vamos a encontrar una serie de sugerencia, de consejos para mejorar más aun la
calidad de la escritura de casos de uso y en encontrar casos de uso y por otro lado esos mismos
patrones nos sirven a la vez como una herramienta de diagnostico para ver si como estamos haciendo
los casos de uso le damos una nueva mirada, vamos refinando el mismo, mejorándolo y de esta forma
logramos la mejor calidad en esa descripción.
¿Cómo se describe un patrón?

Categorías de los patrones de casos de uso

Los patrones de casos de uso están agrupados en dos categorías. La primera se llama patrones
estructurales describen todo aquello que haga a la construcción de un diagrama de casos de uso, a
su identificación y algunas pautas para la descripción de caso de uso. La segunda se llama patrones
de desarrollo agregan otras pautas más para la escritura de casos de uso.
Patrones estructurales
Tiene 4 subcategorías:
Conjunto de casos de uso: describen el comportamiento de un sistema y consisten en un
conjunto de casos de uso, cada uno de los cuales describe un servicio útil que un actor individual
necesita
Casos de uso: cada caso de uso es una colección de escenarios que puestos juntos describen
todas las formas que un actor tiene de alcanzar o fracasar en alcanzar el objetivo
Escenarios y Pasos: los escenarios consisten en una serie de pasos cada uno describiendo una
acción que el actor o el sistema debe hacer para cumplir el objetivo
Relaciones: los casos de uso a menudo interactúan con otros casos de uso. Estos patrones
describen técnicas para manejar comportamiento repetitivo o excesivamente complejo.
Análisis de Sistema Resumen Nicolás Aguirre

Tenemos las 3 subcategorías (falta relaciones) pero este diagrama es útil porque va planteando cada
uno de los patrones, que nombre se le da, que significa y a la vez que correspondencia tiene unos
patrones con otros y eso es útil porque cuando vamos encontrando casos de uso, los vamos
escribiendo, cada patrón de una forma u otra tienen relación.
Patrones Estructurales: Conjunto de casos de uso
1) Compartir una visión clara – SharedClearVersion: cuando nosotros trabajamos en un proyecto
tenemos que saber claramente hacia donde vamos, porque en función de hacia donde vamos a tener
claridad en identificar funciones, en describir que debe hacer el sistema. Este patrón propone que se
preparen una declaración de propósitos que claramente describa los objetivos del sistema y distribuirlo
a todos los involucrados con el proyecto.
2) Limite visible – VisibleBoundary: propone que nosotros cuando vamos modelando un sistema
debemos tener claramente ese límite entre el sistema y el entorno y enumerar los equipos y personas
que interactúan con ese criterio. Concretamente lo que nosotros conocemos y hemos visto que el actor
se grafica hacia afuera de los diagramas de casos de uso y de esa forma estamos viendo que usuarios
van a hacer uso del sistema y vamos encontrado los actores.
3) Reparto claro de roles – ClearCastOfCharacters: lo que propone esto es identificar a estos actores
con los cuales el sistema va a interactuar y el papel que cada actor juega con respecto al sistema.
Cuando hemos visto el diagrama de casos de uso hay una sección donde decimos que hay un espacio
para redactar el rol del actor con especto al sistema.
4) Transacciones de valor para el usuario – UserValuedTransactions: este patrón es el que justifica
como vamos encontrando casos de uso y cuando una función en el sistema la podemos modelar como
caso de uso y que otra cosa no debería ser un caso de uso. Identifique los servicios (requerimientos
funcionales) de valor que el sistema entrega a los actores para satisfacer sus propósitos.
Concretamente es ir encontrando casos de uso que son fragmentos de funcionalidad que responden
a requerimientos funcionales que son servicios del sistema que tiene un objetivo y que logra un
resultado de valor para el actor.
5) Siempre contar una historia – EverUnfoldingStory: esto esta referido a que a medida que vamos
encontrando casos de uso vamos a ir construyendo un diagrama que puede ir creciendo esa cantidad.
Análisis de Sistema Resumen Nicolás Aguirre
Lo que sugiere este patrón es que cuando la dimensión de ese diagrama resulte en una complejidad
en el manejo por la cantidad de casos de uso conviene organizarlos a aquellos casos de usos que
estén hablando de un mismo tema o que estén contando una misma historia entonces yo voy
agrupando, si tengo un diagrama con 200 casos de uso podría crear un conjunto de paquetes,
agruparlos y tal vez cinco conjunto de casos de uso ( de los doscientos casos de uso se pueden
distribuir en cinco conjuntos o paquetes) que agrupan según funciones que estén relacionadas bajo
un mismo tema. Yo podría tener un paquete llamado “Gestión de compras” entonces los casos de uso
que hagan la gestión de compras con proveedores estarán ahí, etc.
Patrones Estructurales: Casos de uso
6) Completar un Objetivo Simple – CompleteSignleGoal: este patrón esta orientado a que escribamos
los objetivos o el objetivo de cada caso de uso. Describa cada caso de uso intentando llegar a un
objetivo completo y bien definido. Ese objetivo puede estar en cualquier nivel de “Siempre contar una
historia” eso habla del patrón anterior que es el 5) en donde agrupamos ese conjunto de casos de uso
y yo puedo agrupar casos de uso que estén relacionados a la misma historia, al mismo conjunto de
funciones.
7) Nombrar con una Frase Verbal – VerbPhraseName: esto se refiere al nombre que le damos al caso
de uso. Nombrar el caso de uso con una frase que contenga un verbo activo que represente la meta
del actor primario. Cuando hemos visto un caso de uso, como se lo representa y su notación, y esto
que dijimos que va con el verbo infinitivo mas el objeto esta hablando de como dar un nombre a un
caso de uso, todo va respondiendo a estas buenas prácticas que en el mundo y otros profesionales
van desarrollando una definición de todo esto.
8) Escenarios más Fragmentos – ScenarioPlusFragments: lo que le sugiere este patrón es que cuando
nosotros empezamos a describir el caso de uso conviene ir describiendo el escenario (conjunto de
pasos) escribiendo el curso normal y luego encontrando las alternativas y sus posibles fracasos. Lo
que sugiere el patrón es que siempre cuando empecemos a escribir un caso de uso redactemos los
pasos del curso normal y luego van identificando y a posterior detallando los escenarios alternativos y
los posibles fracasos. Es como una forma mas ordenada de llegar a una mejor descripción.
9) Alternativas Exhaustivas – ExhaustiveAlternatives: esta orientado al trabajo de análisis que tenemos
que cuando describimos una historia (caso de uso) el curso normal en general sale sin problema, pero
a veces las rutas alternativas no las logramos identificar, la idea de este patrón es que nuestro trabajo
de análisis tiene que ser, poder lograr capturar todas las alternativas y fallas o fracasos posibles que
ese caso de uso deba manejar. La descripción del caso de uso es a lo que a futuro debemos programar
entonces ahora estamos describiendo la lógica del proceso y cuando uno va programando tiene que
ir modelando o creando los distintos códigos para las situaciones normales y todas las situaciones de
si pasa esto o si pasa el otro y vamos utilizando las instrucciones y lo necesario en ese lenguaje de
programación. Para llegar a ese punto y pensar eso uno describe esta historia con la plantilla (caso de
uso) o un diagrama de flujos donde uno hace una secuencia de pasos, entonces la idea es que
podamos capturar todas las alternativas y fallas. Si no descubrimos todas esa descripción de casos
de uso estaría incompleta.
10) Adornos – Adornments : esta orientado a que cuando nosotros diseñemos una plantilla la
estructura debe tener los puntos ya vistos a describir (inicio, desarrollo, fin) pero además uno puede
agregarle otros elementos que son los adornos, el campo de observaciones al final, una trazabilidad
entre casos de uso, esos son lo que se denomina adornos, crear campos adicionales en la plantilla,
en el caso de uso que este fuera del texto del escenario, del curso normal o del alternativo para incluir
Análisis de Sistema Resumen Nicolás Aguirre
información suplementaria que sea útil asociar con el caso de uso. Por ejemplo, esto de decir si el
caso de uso es concreto o abstracto son todos adornos que se agregaron como un dato útil en la
especificación de ese caso de uso.
11) Preciso y legible – PreciseAndRedable: este patrón esta orientado a la descripción de caso de uso
que tenga suficiente detalle de modo tal que tenga la precisión suficiente y a la vez que sea legible.
Este escrito en un lenguaje en donde yo se lo muestro al cliente y si el lo lee lo puede comprender por
eso uno hace una descripción en un lenguaje no técnico. Cuando leen los casos de uso el cliente
depende del proyecto que nos toque trabajar y el nivel de cuanto va a estar involucrado ese cliente en
el sistema y el nivel de conocimiento que pueda tener y el interés que tenga en leerlo, pero los casos
de uso se escriben en un lenguaje usando un vocabulario del cliente de modo tal que lo pueda leer.
Escriba el caso de uso de modo que sea lo suficientemente legible para que los clientes puedan leerlos
y evaluarlos. Y lo suficientemente preciso para que los desarrolladores comprendan lo que están
construyendo. Esta descripción del caso de uso es la lógica del proceso para que después se pueda
codificar, si en el equipo de sistemas trabajo con un programador le tiene que quedar claro lo que debe
hacer esa función y que debe programar.
Patrones Estructurales: Escenarios
12) Condiciones detectables – DetectableConditions: habla de condiciones detectables, esto también
está trabajando con todas nuestras rutas alternativas que están definidas y que son aquellas que
aporten en algo a la descripción y que sean útiles. Todos los escenarios posibles que voy pensando
deben ser cosas que realmente pueden llegar a ocurrir y a la vez no buscar condiciones que no puedan
darse y describirlas igualmente, a eso se refiere con que este patrón incluya solamente condiciones
detectables y perceptibles. La idea es un punto exacto entre describir todo aquello que pueda ocurrir
pero que sea valido y útil y no describir rutas alternativas que nunca puedan ocurrir y que estamos
describiéndolas y no aportan nada. También sugiere que fusione condicione que tienen el mismo
efecto neto en el sistema, esto hace referencia a que esta ruta alternativa y este otra son semejantes
y por tanto si hablan de lo mismo las tengo que unir.
13) Pasos nivelados – LeveledSteps: mantenga los escenarios con una cantidad de pasos nivelados.
Idealmente los pasos estarán todos en niveles similar y a un nivel de abstracción justo debajo del
objetivo del caso de uso. Esto se refiere a que si nosotros trabajamos en equipo la forma de escritura
tal vez yo me ponga a escribir de una forma muy detallista con muchos pasos y tal ve mi compañero
de equipo tiene una forma de escribir que es muy general, nosotros tenemos que describir todos los
casos de uso con una forma de escritura que este nivelado, después de repente un caso de uso
complejo puede tener mas pasos y uno mas simple menos pasos, no, acá lo que habla este patrón es
que la cantidad de pasos sean nivelados con un nivel de escritura y una forma de llevar adelante esa
escritura que este semejante en todo el equipo que trabaja. Si hablo de pasos semejantes como la
baja de un cliente y la baja de un producto la forma de escritura tiene que manejar una forma
semejante, por ejemplo.
Patrones Estructurales: Pasos
14) Actor intenta cumplir – ActorIntentAccomplished: lo que indica es que la descripción de cada caso
debe diferencia lo que hace el actor de lo que hace el sistema. Cada paso que nosotros idnetifiquemos
en uno debe ir lo que hace el actor y en otor va lo que hace el sistema.
15) Porgresar hacia delante – ForwardProgress: la idea es que cuando tengamos una descripcion hay
que eliminar o unir pasos que no hagan avanzar al actor hacia la meta. Supongamos que el actor
Análisis de Sistema Resumen Nicolás Aguirre
ingresa los datos del domicilio, en otro paso ingresa el numero de casa, el nombre de la calle, el
numero de departamento, dividir eso por pasos no aporta nada, todo eso se puede unir, habla que
cada paso sea significativo y vaya progresando hacia delante de esa manera simplificando la cantidad
de pasos.
16) Tecnología neutral – TechnoogyNeutral: este patrón lo que sugiere es que cada descripción de
cada paso es independiente de la tecnología que se utilice, cuando describamos no nos peguemos a
el recurso visual del prototipo o a situaciones de como se van a visualizar, sino que hacemos una
abstracción y definimos el paso independiente de como se esta aplicando hoy con un recurso visual,
un icono de alguna forma. De esa forma la descripción se mantiene en el tiempo independiente de que
la forma en que la implementemos pueda cambiar.
Patrones Estructurales: Pasos
17) Comportamiento común subordinado –Common SubBehavior: es expresar cursos de acción
compartidos con caos de uso de “inclusión”. Extraer los pasos comunes y ubicarlos en otros casos de
uso. Si recuerdan cuando vimos un caso de uso de inclusión puede surgir de un caso de uso base y
otro caso de uso base que ejecutan un comportamiento común y yo extraigo ese comportamiento
común a un nuevo caso de uso, hay un patrón que atiende y orienta que eso es útil y bueno sacar ese
comportamiento común a un caso de uso y que se dé esto de inclusión.
18) Interrupciones ocmo extensiones – Interruptions AsExtensions: un poquito la palabra lo tiene claro,
crear un caso de uso de extensión cunado un curso de acción alternativo interrumpe un numero de
pasos en un escenario. Este patrón tiene que ver con lo que propone la relación de extensión que bajo
cierta condición o bajo cierta situación que uno valida describe una situación alternativa o un curso de
acción alternativo y lleva esa porción a un caso de uso de extensión.
19) Promover alternativas – PromotedAlternative: este patrón busca considerar también mover a otros
casos de uso situaciones alternativas complejas disminuyendo la complejidad del caso de uso
llevándolo a otro. Acá podemos tener como inclusión o como extensión porque como estamos
disminuyendo la complejidad podría ser si surge de una ruta alternativa o si solamente son situaciones
complejas para disminuir la complejidad en un solo caso de uso.
20) Abstracción capturada – CaptureTheAbstraction: lo que propone es que se puede crear casos de
uso abstractos generalizados y colocar en casos de usos separados cada escenario distinto que
especializa esa abstracción. Concretamente en nuestra relación de generalización entre casos de usos
donde el caso de uso padre es una abstracción y se va a definir los pasos que van a ser heredados
por los casos de uso hijo y en los casos de uso hijo van a especializar esa abstracción, eso significa
que hereda el comportamiento del padre y le agrega el comportamiento propio y termina describiendo
el caso de uso de esa forma.
Patrones de desarrollo
Dentro de los patrones de desarrollo están agrupados aquellos patrones que tienen que ver con el
trabajo en equipo y los estilos de escritura, de redacción y como se pueden mejorar o mejores practicas
al momento de escribir cuando somos varios los que vamos trabajando y a la vez un refinamiento que
uno de la de una segunda vuelta a la primera escritura de los casos de uso.
Tenemos en este caso para patrones de desarrollo tres subcategorías: Equipo, Proceso, Revisión.
La idea es que estos patrones cubran tres tópicos, la conformación de los equipos por eso el primer
grupo de equipos que escriben los casos de uso y los otros dos hablan de las técnicas, una para crear
Análisis de Sistema Resumen Nicolás Aguirre
los casos de uso y otra para mejorar porque nunca un caso de uso se escribe una primera vez y queda
perfecto, siempre necesita revisiones.

Patrones de desarrollo: Equipo

21) Equipo de escritura pequeño – SmallWritignTeam: la idea es que cuando trabajemos en un
proyecto es bueno que no sean una gran cantidad porque mientras mayor sea la cantidad de personas
en la escritura mas variedad de estilos y mas diferencias vamos a tener, todo dependerá de las
características del proyecto. La idea es trabajar en un grupo reducido y el patron sugiere que en ese
equipo a veces esta bueno que uno escriba y el otro revise porque pueden hacerse mejoras.
22) Audiencia Participativa – ParticipatingAudience: busca involucrar al cliente y los usuarios en el
proceso de desarrollo , es decir, a todos los que van a estar del lado que van a hacer uso del sistema
para saber reconocer su vocabulario y saber si las funciones que vamos haciendo y la descripción a
veces va con forma o no entonces habla de este tipo de aspectos a considerar.
23) Equipo Balanceado – BalancedTeam: la idea es que la conformación del grupo de trabajo y del
equipo este bastante bien equilibrado y balaceando con los conocimientos de cada uno, entonces
habla de como el equipo debe estar nivelado y podamos tener un trabajo en conjunto y trabajar bien
alineados.
Patrones de desarrollo: Proceso
24) Respirar antes de profundizar – BreadthBeforeDepth: eso significa que todo el esfuerzo que uno
va haciendo cuando va describiendo y que va primero por ese curso norma y después progresando
con los detalles y también abierto a esa estrategia de antes de escribir en el detalle pensar la lógica
Análisis de Sistema Resumen Nicolás Aguirre
en forma macro, el esqueleto o la secuencia de pasos genérica que ese paso de uso debe realizar y
luego se meten de lleno en lo profundo a trabajar en el detalle
25) Desarrollo en espiral – SpiralDevelopment: un caso de uso se va construyendo de manera iterativa,
uno va trabajando en ese curso normal, luego va agregando detalles, los cursos alternativos, los
fracasos y va logrando la precisión y la exactitud por eso va en forma progresiva, por eso dice
desarrollo en espiral.
26) Formas Multipples – MultipleForms: habla de seleccionar el formato en base a los riesgos
asociados con el proyecto y las preferencias de las personas involucradas. Esto habla de los distintos
templates y formas en que nosotros vamos a describir casos de uso que el equipo va a tener que
definir una estructura que contemple todos los aspectos necesarios a describir y según las
características del proyecto serán el formato y el diseño según las características del equipo de como
vamos a describir los casos e uso.
27) Revision de Dos Capas – TwoTierReview: la idea es que la revisión en la escritura este hecha por
el mismo grupo que trabaja internamente y si somos dos analistas de esta cuestión en dos capas y la
idea es que después de esa descripción de caso de uso seria bueno que le haga la revisión el resto
del equipo un involucrado no que todos tengamos que estar leyendo todo, pero esta cuestión de que
uno solo escriba y eso hace a la versión final y nadie mas lo lea es lo que no se sugiere. Siempre es
útil que haya una revisión de alguien mas de la escritura que puede ser del mismo equipo o de otra
parte del equipo, la idea es que siempre aporta la revisión de otra mirada de otra parte del equipo para
tener una devolución y tener una mejor actitud.
28) Tiempo de Dejar – QuittingTime: llega un momento donde si yo veo el caso de uso, cada vez que
lo leo le agrego una mejora, llega un momento en donde si esta completo y todos los escenarios los
adecuados, las alternativas y los fracasos se han identificado y están descritos es momento de dejar
ese caso de uso porque quedo descrito de forma correcta y ya no le voy a seguir cambiando cosas,
no implica que la lógica cambie sino que se refiere a que muchas veces se cambian muchas cosas de
forma exhaustiva, pero llega un momento que hay que parar.
29) Licencia de Escritor – WritersLicense: por mas que yo con el equipo acuerde las pautas, los niveles,
llega un momento donde la forma que redacta una persona y otra a veces llega a haber mínimas
diferencias y eso es lo que se llama el estilo propio de escritura y pueden quedar un conjunto de casos
de uso con un estilo y otro con ese tipo de redacción, no con diferencias y si teniendo en cuenta todos
los mismos criterios con las pautas establecidas. Llega un momento donde yo no voy a escribir todos
los casos de uso de mi compañero porque me gusta como yo lo escribo, no tiene que ver con eso
justamente hay que respetar esos estilos de redacción y en esos puntos es combinado con el tiempo
de dejar (28) si esta bien y está completo el caso de uso y cubre todos los escenarios posibles,
suficiente y se respeta la distintas formas en la que escribimos algo.
Patrones de desarrollo: Revisión

Una vez que están descritos los casos de uso hay una vuelta nuevamente para ver si quedo
consistente, está completo o si hay algo que se pueda mejorar.
30) Redistribuir la salud – RedistributeTheWealth: mover un pasaje largo, difícil de manejar o
comlpicado a otro caso de uso. Esto significa que nos quedo un caso de uso, lo describimos y nos
Análisis de Sistema Resumen Nicolás Aguirre
queod muy complejo entonces ahí yo lo vuelvo a leer y esta bien descripto esta completo y respeta los
otros 29 patrones, pero seria talvez mejor hacerlo mas simple entonces extraigo un conjunto de
acciones relacionadas, disminuyo la complejidad y creo otro caso de uso. Eso porque el caso de uso
luego va a ir un equipo de desarrollo y se va a poner a programar si es muy complejo también le va a
llevar mayor tiempo, puede tener mayor dificultad en la compresión y si yo le disminuyo la complejidad
favorezco al trabajo en equipo a la parte de programación y desarrollo.
31) Mezclar gotitas – MergeDroplets: esto es la contrapartida de lo anterior, yo quizás empecé a definir
casos de uso y cuando los escribir son pedacitos muy pequeños que dan fragmentos muy fraccionados
y talvez esos dos casos de uso son consecutivos están relacionado y el conjunto de acciones en forma
completa puede cumplir un objetivo y los podría integrar, cosas muy fragmentadas en distintos casos
de uso puede unirse en uno siempre que estén relacionados, cumplan el objetivo y el conjunto de
acciones sea posible
32) Limpiar la casa – CleanHouse: puede ser que cuando yo encontré los casos de uso me pareció
que esta funcionalidad era útil y después la describí y tal vez no aporta al sistema o no va a ser tenida
en cuenta en la propuesta, entonces hay que remover aquellos casos de uso que no agregan valor al
sistema o que ya no están en la lista activa de casos de uso.

Estrategias para aplicación de patrones de caso de uso

Cada vez que se nos pida definir el objetivo del sistema de información estamos aplicando el patrón 1
de compartir una visión clara.
Cada vez que se nos pide construir el diagrama de casos de uso, encontrando actores y casos de uso,
cuando vamos encontrando actores y dibujamos el limite del diagrama es porque estamos
considerando todo lo que aporto el patrón 2 de limite visible.
Cuando nos dicen describir el rol del actor es porque estamos usando el patrón 3 de reparto claro de
roles
Análisis de Sistema Resumen Nicolás Aguirre
Cuando nos dicen de identificar casos de usos es el patrón 4 de transacciones de valor para el usuario.
Cuando nos dice que tenemos que determinar el nombre del caso de uso es el patrón 7 de nombrar
con una frase verbal .
Cuando hemos definido los objetivos del caso de uso es el patrón 6 completar un objetivo simple
El patrón 5 no lo vamos a llegar a hacer este año.
Cuando nosotros estamos haciendo el diagrama de casos de uso y vamos relacionando con algún tipo
de relación entre casos de uso ya sea inclusión o extensión o de generalización estamos aplicando los
cuatro patrones posibles entre relaciones. Si es de inclusión puede ser el patrón 17 que es
comportamiento común subordinado o el 19 que es promover alternativa. Si hablamos de relaciones
de extensiones podemos estar aplicando el patrón 18 interrumpir con extensiones o el 19 promover
alternativa, el 19 participa en los dos porque si es complejo el caso de uso y lo extraigo en otra parte
si siempre se ejecuta una inclusión y si según cierta condición pueda o no llamarse es una extensión
por eso puede estar en cualquiera de los dos. Y cuando encuentre el caso de uso con una relación de
generalización estamos aplicando el patrón 20 de abstracción capturada.

Siempre que hagamos una descripción debe estar completa y detallada, pero para darnos cuenta de
esto la idea es siempre empezar con el curso normal, vamos encontrando las alternativas, pero
después las describimos y del curso normal vamos pensando toda alterativa valida y posible bajo
ciertas condiciones para saber después que las estamos detectado bien y cada paso los vamos
describiendo en forma detallada.
Análisis de Sistema Resumen Nicolás Aguirre
Al considerar todo eso estamos considerando el conjunto de patrones:
Patrón 8 Escenarios más fragmentos: primero lo normal, después lo alternativo.
Patrón 9 Alternativas exhaustivas: todas las alternativas que encontremos.
Patrón 11 Preciso y legible: el detalle suficiente, de todos los datos y acciones en forma completa
Patrón 12 Condiciones detectables: aquellas alternativas que sean validas y necesarias cuando estén
completas. No caminos no posibles, si no va a ocurrir lo descarto.
Patrón 15 Progresar hacia delante: esa estrategia de primero pensar el esqueleto y a grandes rasgos
cuales son los pasos y después van a detalle y escribimos cada una de las cosas que implica la
descripción detallada.
Nosotros vamos a tener distintos pasos y tenemos que diferenciar los pasos que hace el actor de lo
que hace el sistema y ese es el patrón 14 Actor intenta cumplir. Cuando redactemos tenemos que
tener cada una de esas cosas separadas.
Análisis de Sistema Resumen Nicolás Aguirre
Cuando dijimos de no hacer referencia a aspectos de implementación o diseño de interfaz es el patrón
16 de tecnología neutral.

Cuando nosotros tengamos un diseño de prototipo la idea no es poner el nombre exacto de un botón,
no hablar de los recursos del mismos como “mostrar una grilla” lo que tenemos que indicar es que
muestra los datos, por ejemplo. Es la acción descripta , el paso descripto independiente del elemento,
no se escribe que el RPP selecciona el botón aceptar. Tenemos que ser independientes de la
tecnología.
Cuando describamos el caso de uso vamos a tener que saber distinguir en forma precisa cada dato
que se ingresa y cada dato que se registra, cada dato que se consulta actualiza y demás y a la vez
diferenciar el ingreso de datos de aquellos que pueden ser seleccionados de una lista de datos
existentes. Al distinguir trabajar con esto estamos con el patrón 11 Preciso y legible. No podemos
poner que el sistema guarda datos del paciente, sino que debemos poner que datos guarda, pero
además debemos distinguir la
selección del ingreso. Cuando
nosotros hablamos de ingreso de
datos significa que el actor ingresa
datos en una ventana, significa que
en un teclado va a escribir algo y el
sistema lo toma, hay una pantalla e
ingresa algo. Cuando describamos
un caso de uso tenemos que
pensar a donde va a parar esto para
que hagamos una descripción
correcta. Si yo digo selección de
datos quiere decir que hay una
información que el sistema muestra
para que el actor seleccione, eso
quiere decir que el sistema fue a
una base de datos, encontró información, la muestra y el actor selecciona, eso se tiene que describir
también en forma diferenciada en una descripción de casos de uso.
Análisis de Sistema Resumen Nicolás Aguirre
El patrón 12 de condiciones detectables habla de que cuando surge una alternativa indiciar claramente
el camino que va, por un lado, cual me quedo por curso normal y cual va por la alternativa.
Uno cuando va haciendo la descripción se va dando cuenta si tiene comportamiento común porque
hay dos descripciones que tengan algo entonces los llevo o si me quedo muy chiquito y yo atomice
mucho lo puedo unir, justamente el 30,31 y 32 hablan de revisar nuevamente las descripciones y en
función de eso pueda modificar el diagrama o unir o crear nuevos casos de uso.

El patrón 26 habla de formas múltiples, las plantillas pueden cambiar, pero no nos tiene que afectar y
a su vez esas plantillas pueden tener adornos (patrón 10) que pueden estar o no.
En general los 32 patrones son todos un combo completo de sugerencias de todo lo que debemos
considerar al describir y encontrar casos de uso. Algunos se aplican en forma mas puntual o algunos
son directamente relacionados a algún concepto como esto de los templates, pero todo esto en
conjunto es necesario que los identifiquemos, conozcamos y aprendamos para hacer un buen
modelado de casos de uso.
Maquina de estados
La palabra estados nosotros venimos cuando estamos trabajando en el diagrama de clases que
cuando hablábamos de un pedido decimos que tiene un estado, ese es el concepto que el diagrama
que estamos por ver trata de capturar y darnos algunos elementos para hacer una representación
gráfica.
Nosotros vamos a tener un comportamiento que observar de un objeto en forma individual y ese
comportamiento que va a tener el objeto que pertenece a una clase va a ser modelado a través de una
maquina de estados. Ese comportamiento nos va a mostrar o especificar una secuencia de estados,
no un único estado, un ciclo de vida un camino en donde un objeto va a ir transcurriendo a lo largo de
su vida, desde que se crea el objeto, que tiene existencia donde tiene un estado inicial e ira cambiando
Análisis de Sistema Resumen Nicolás Aguirre
de estado en función a una serie de facciones que las vamos a llamar eventos y va a ir respondiendo
ante ese evento, ese estimulo que recibe y cambia de estado, entonces nosotros vamos a modelar el
comportamiento de un objeto en su ciclo de vida o a lo largo de su vida para ir mostrando que acción
tiene, que reacción tiene y como va cambiando de estado siendo ese el concepto de ese
comportamiento.
Entonces nos vamos a valer de un diagrama denominado maquinas de estado que nos permite
representar este comportamiento de este diagrama o de este objeto con sus estados y esto esta
mostrando un aspecto dinámico de un sistema. Recordemos que tenemos distintos diagramas, unos
muestran aspectos estáticos y otros aspectos dinámicos. Este diagrama se encuadra dentro de una
vista dinámica de algo o del comportamiento de un objeto en el sistema.
La maquina de estado es una herramienta muy útil que es eficiente que es sencilla de utilizar, que es
adaptable y que representa visualmente de forma muy clara lo que queremos representar. En ambos
paradigmas, tanto estructurado como orientado a objetos existe un diagrama para representar el
comportamiento y cambio de estados. Es algo que cuando nosotros modelamos sistemas siempre se
nos va a presentar que tenemos algunos aspectos a considerar y tenemos que representar ese cambio
de estado es muy normal que en sistemas manejemos estados para un concepto, para un objeto o
para una clase o también podemos usar maquinas de estado para distintas situaciones. Es muy
aplicable en distintos conceptos.
Nosotros lo vamos a utilizar al modelar una clase para mostrar el comportamiento de un objeto y vamos
a conocer ahora los distintos elementos para su representación considerando estados, eventos y
transiciones.
Nosotros siempre vamos a tener que tener un diagrama de clases y en ese diagrama de clase una
clase que tenga un atributo en donde queramos representar el estado de los objetos de esa clase.

Es un diagrama que esta dentro de comportamiento y que muestra aspectos dinámicos, tenemos que
ir sabiendo cada diagrama dentro de que grupo esta y que aspecto visualiza. Después tenemos las
vistas de UML que debemos saber a qué vista corresponde.
Análisis de Sistema Resumen Nicolás Aguirre
UML me va a ofrecer una serie de elementos para hacer esta representación y las maquinas de estado
van a usar este diagrama. Las maquinas de estado van a mostrar una serie de estados destacando
cuales van a ser el flujo de control o la transición para que un estado que estamos encontrando que
situación o evento ocurre y como cambia el estado y en que condiciones queda ese objeto.
Esta notación permite visualizar el comportamiento de un objeto dirigido por eventos de forma que
permite destacar los elementos más importantes en su vida.
Elementos para representar un diagrama de estado
Vamos a tener lo siguientes:
Los primeros tres son los mínimos e
indispensables para poder construir un
diagrama, pero a la vez a medida que
vamos analizando sistemas más
complejos también vamos a tener que
tener que cuenta que pueden existir
estados compuestos y subestados.

Estado
El estado va a ser una condición o situación en la vida de un objeto. Llego ese estado porque ocurrió
un evento, un estímulo, una condición, alguna actividad o algo y quedo en una situación, una condición.
El objeto va a permanecer en ese estado hasta que venga un nuevo estimulo, una situación que ocurra
y provoque el cambio de estado.
Es una condición o situación en la vida de un objeto durante la cual satisface alguna condición, realiza
alguna actividad o espera algún evento. Un objeto permanece en un estado durante una cantidad de
tiempo finito, va a quedar en esa condición, en ese estado, hasta que venga un nuevo evento y
provoque ese cambio de estado.
Para representar un estado se hace un recuadro con sus bordes redondeados y dentro del mismo
tiene el nombre del estado que queremos indicar. Normalmente se trata de expresarlo en una palabra
pero habrá situaciones donde se usara mas de una pablara. Se expresa también en verbo conjugado,
como algo que ya ha ocurrido, si llegamos a ese estado es porque el evento o el estimulo que provoco
que el objeto actúe y cambie de estado llego a un nombre a una situación que ya ocurrió y permanece
en ese estado hasta que un nuevo evento lo haga cambiar, por eso la expresión no se usa en verbos
activos o verbos en infinitivos, sino algo que ya ocurrió y queda en ese estado hasta que ocurra algo
nuevo.

El nombre de estado es una cadena de texto cuya denominación lo distingue a ese estado de lo que
estamos identificando. Normalmente se pone en mayúscula la primer letra pero podemos escribirlo
todo en mayúscula. Esto no tiene una notación tan estricta como para escribir los atributos, las
Análisis de Sistema Resumen Nicolás Aguirre
responsabilidades y el nombre de clases, pero es una sugerencia de cómo es la denominación , puede
ir la primera letra en mayúscula pero no es que no puede haber espacios, no tiene ese tipo de
expresión. La sugerencia también es que sean nombres cortos , concretos, claros, de lo que queremos
expresar como es el estado y considerando el vocabulario del sistema que se esta modelando.
Los términos a darle como nombre son aquellos que cuando nosotros hicimos el trabajo de elicitación
sean expresiones o las situaciones que el cliente, ese futuro usuario esta usando como expresión.
Ejemplo
Cuando nosotros vamos representando conceptualmente las transacciones o las situaciones en las
cuales ese objeto puede ir cambiando de estado. Por ejemplo los datos del cliente se registra, esa
clase no tiene un atributo estado no hay que modelar un diagrama de estado.
Supongan el ejemplo siguiente:

Se genera un presupuesto, viene un cliente, solicita un mueble, se le hace un presupuesto en función

de lo que esta necesitando si se concreta la venta hace una seña, se va a hacer el diseño y la
fabricación propiamente, luego la instalación y el cobro.
Nos vamos a detener en el presupuesto que es una transacción y esa transacción tiene un concepto
de estado, lo que quiere decir que, un pedido en particular que me esta haciendo el cliente yo lo tengo
que presupuestar viendo lo que pide, generando el mismo en función de los módulos, las partes que
va a contener ese mueble y sacare un total de lo que le ofrezco como costo de realizar el mueble. Ese
presupuesto va a estar en un estado inicial, el estado es una situación después que ocurre una
actividad, una situación donde queda el objeto, es un resultado, algo que realizo. Nombres que pudo
haber tenido podrían ser “Generado” “Realizado” todo dependerá en ese negocio cuando yo voy
charlando con el cliente como consideran ellos el concepto que le dan a ese presupuesto, pero de esa
forma va encontrando cuando uno va haciendo la elicitación y luego va creando el diagrama de clases
encontró que existe la clase presupuesto que va a tener una serie de atributos como numero de
presupuesto, fecha de presupuesto y habrá un atributo que diga “estado del presupuesto”. Cuando
nosotros tengamos una situación de estado de un concepto, de una clase es cuando podemos
empezar a construir el diagrama de estado, mi primera acción es encontrar que estados tendría esa
clase y los objetos de esa clase, recordando que estamos modelando el comportamiento de un objeto
a lo largo de su vida, la existencia de ese objeto y recuerden que una clase es un conjunto de objetos
con estructura y comportamiento común.
El cliente puede a ese presupuesto aceptarlo o no,
de ahí yo voy analizando: ¿esa situación que lo
acepte o no hace algo a mi sistema? Si porque el
rechazado significa que ahí termina el proceso o
hago un nuevo presupuesto o alguna otra acción y
Análisis de Sistema Resumen Nicolás Aguirre
el aceptado significa que voy a tener el trabajo con el cliente, voy a proceder a cobrarle la seña y luego
cuando haga todo el trabajo se concreta. Entonces de esa forma va saliendo, es analizando la situación
que hemos hecho la elicitación, modelamos el negocio, conocemos como funciona el procedimiento,
construimos el diagrama de clases y a partir de ahí un atributo de una clase empezamos a encontrar
los estados y vamos pensando en función de cuales son los representativos y significativos que
signifique una acción o un evento que haga que el objeto cambie de estado y vamos encontrando los
nombres.
Estado: estado inicial y estado final
Son estados especiales ya que ambos son pseudoestados.
Todo diagrama se empieza a graficar con un símbolo en particular que lo vamos a llamar estado inicial,
la representación del mismo es un punto relleno, es una forma de empezar la graficación que indica
que en ese punto inicia la maquina de estado o el subestado que ya se verá.
Normalmente es como si esa clase va a tener un diagrama de estado el diagrama se empieza a
representar con este pseudoestado que seria este grafico chiquito. Una vez que encontremos un
estado todo diagrama va a terminar con un estado final, con un símbolo donde vamos a concluir todos
los cierres del diagrama que se representa con un circulo relleno y un círculo mayor en blanco
indicando que la máquina de estado ha finalizado su ejecución.

Transición
Este elemento es aquello que me va a permitir mostrar una relación de un estado que pasa al siguiente
estado porque yo voy encontrando estados ahora como se cual es el primero y cual va a continuar
después del primero o cuales pudiendo tener distintos caminos. La transición es una relación entre
dos estados que indica que un objeto que esta en el primer estado de donde surge la relación realizara
una serie de acciones considerara una serie de eventos y entrara al segundo
estado bajo las condiciones que se cumplan para poder cambiar de estado.
El primero se llama estado origen, el segundo se llamara estado destino.
La transición es una flecha abierta en donde parte de un estado primero
(estado origen) y llega a un estado segundo (estado destino).
Concretamente es la representación de esa flecha y el sentido indica origen
y destino.
Análisis de Sistema Resumen Nicolás Aguirre
La transición por si sola no puede trabajar, sino que la transición es la graficación de que estado origen
a que estado destino va, pero va acompañada de un evento de cual es el estimulo que provoca el
cambio de estado.
Evento
Es la aparición de un estimulo que puede disparar una transición de estado, es un acontecimiento
importante a tomar en cuenta por el sistema y va a ir acompañando al nombre de la flecha y esto es
lo que se llama un “evento de llamada”.
Cada vez que empecemos a hacer un diagrama de estados, encontramos estados, partiremos de un
estado inicial, que era ese grafico del círculo relleno, vamos encontrando estados, hacemos
representación de las transiciones y vamos poniendo el evento que genera la transición para cada
cambio de estado.
El nombre del evento se omite en las transiciones de finalización, es decir, cuando la transición esta
dirigida hacia el pseudoestado final. Todas las transiciones llevan evento, casi todas, menos aquellas
transiciones que se dirigen al pseudoestado final.

Transición y evento
Nosotros tenemos una sintaxis para poder escribir ese nombre del evento que va a llevar el nombre
que le demos, los paréntesis, y pueden llegar a tener entre los corchetes una condición de guarda y
puede llegar a tener alguna acción que queramos precisar.

La notación del evento a tener la misma notación que tenemos para las responsabilidades en un
diagrama de clases que es la primera palabra en minúscula y las demás palabras cada primera letra
de cada palabra que siga va en mayúscula, el resto en minúscula sin espacios, ni guiones ni ningún
otro signo.
Ejemplo
Cada vez que empecemos a representar un diagrama de
estado vamos a usar el evento inicial que seria el
pseudoestado que es una forma gráfica de indicar que
tengo una máquina de estados y voy a empezar a
presentar la creación de un objeto o el inicio de un objeto
en su comportamiento. Siempre va a ir acompañado del
evento que va a tener este nombre con esta notación
indicada anteriormente, siempre lleva nombre de evento y
opcionalmente puede tener condición de guarda y
acciones. De generado que es el presupuesto puede llegar a acetarlo o rechazarlo, yo muestro el
Análisis de Sistema Resumen Nicolás Aguirre
estado origen, hay una nueva transición y muestro el estado destino y le agrego el nombre del evento
que genera ese cambio de estado. En este caso es el cliente hablo y dijo que acepta el presupuesto,
en el sistema significa algún caso de uso que haga la acción de registrar aceptación de un presupuesto
y a nivel de la clase, en la clase presupuesto el estado va a cambiar, es el mismo presupuesto, pero
no va a estar mas generado, sino que va a estar aceptado y esa es la forma de representarlo aquí.
Veamos que significa la condición de guarda y las acciones.
El evento es lo que provoca el cambio de estado y acompaña a la transición.
Una condición de guarda que sería. Nosotros a veces podemos tener dentro de un mismo evento que
analizar una situación en particular y esa condición o esa situación de validación la van a agregar en
el evento. Normalmente se expresa como una situación o validación booleana de algo que si o no o
algo que puede ocurrir de una forma u otra siempre se escribe entre corchetes y va a ir acompañando
al evento teniendo que considerar si me aporta en el diagrama que yo tenga un evento y le agrego una
condición de guarda porque me aporta la condición por la cual se ocurre ese cambio de estado y esa
transición lo voy a agregar en el diagrama. Por eso se dice que es opcional cuando es clarito el evento
y no hay ninguna situación o validación extra que indicar no es necesario.
Seria este cambio de estado y a la vez que otros efectos dispara esta transición en estos que estamos
queriendo modelar, siempre esta relación a otro objeto u otra situación. Significa que un objeto en su
ciclo de vida cambia de estado y a la vez provoca una acción en otro objeto que haga otra cosa y
también es opcional, todo depende de cómo lo vayamos modelando.
Ejemplo Integrado

Tenemos el estado inicial el primer evento que es crear, yo genero presupuesto, voy a crearlo, el objeto
se crea y parte de un estado con un nombre que se llama generado. Cuando el cliente me da la
respuesta me puede decir que lo acepta o lo rechaza siendo ese el siguiente evento.
Yo podría tener el evento registrarRespuesta y cuando tengo el camino de generado a aceptado el
evento es registrarRespuesta y tengo desde generado a rechazado el evento también es
registrarRespuesta. En este caso cuando tengo un mismo evento es ahí donde por ejemplo que me
va a ayudar a indicar cual es la condición que voy para este camino y cual es la condición de que voy
para otro y ahí agrego entre corchetes la condición de guarda. Normalmente suele ser una expresión
booleana o lo importante es que lo expresemos como la condición que genera por cada ruta a la que
voy a ir. En este caso voy a poner “respuesta = si” para el camino aceptado y en el otro corchete, en
la otra condición de guarda para rechazado “respuesta =no”. De esa forma voy completando la sintaxis
de la transición y el evento.
Análisis de Sistema Resumen Nicolás Aguirre
La barra en el caso de aceptado significa que cuando el cliente me dice que, si yo voy a hacer otra
acción, es el efecto que provoca este cambio de estado, significa que tengo que tengo que empezar a
comprar los materiales, la materia prima para fabricar el mueble entonces dispara una acción para otro
objeto, para otro concepto. En este caso, generar el pedido de cobro. La acción se va a expresar
siempre y cuando se aporte algo y de un efecto en otro efecto, que el otro objeto será una orden de
compra se va a generar y significa que estará conectado también generado o pendiente de entrega u
otro.
En el caso de la respuesta no “no” hay otra acción por eso no pongo nada más, es rechazado y
rechazado es el estado final entonces acá vamos completando el estado final que se representa c el
circulo relleno y un segundo circulo en blanco. Siempre que tengamos un estado final no lleva nombre
esa transición, no lleva otro evento porque significa: “llegue a rechazado, hasta ahí termino el ciclo de
vida de este objeto, de este presupuesto y esto es un estado final” entonces yo aquí lo marco de esta
forma visualmente este pseudoestado de estado final y no le pongo nombre porque esto solamente
indica que ese llego a su fin.
Si fuera por el camino de aceptado que tiene esos puntos continuaremos el presupuesto después de
aceptado que situación ocurre, tiene que pagar una seña, una vez que pague la seña tengo que poner
señado y sigue el proceso.
Auto transición
A medida que vayamos modelando van a ir surgiendo otras consideraciones como la auto transición.
Cuando yo tengo que estoy en un estado, ocurre un evento que debo considerar porque hay otros
atributos asociados a ese evento, pero este objeto permanece en ese estado es donde voy a usar la
representación que se llama auto transición. Significa que el estado no cambia, pero el objeto en sus
otros atributos sufrió algún cambio, tuvo una modificación o algo.
Una auto transición se denomina como aquella transición cuyo estado origen y estado destino son el
mismo, esto significa que un evento dispara la transición, en teoría se va de ese estado, pero termina
la ejecución de ese evento y se mantiene o vuelve al mismo estado.

Si yo modifico un presupuesto que tiene una vigencia y el presupuesto todavía no fue aceptado ni
rechazado pero a mí me interesa modelar la modificación del presupuesto y que de a partir de ahí
corren 10 días mas hasta esperar su aceptación. Entonces el objeto en si con sus otros atributos, el
objeto de la clase presupuesto ha tenido algunos cambios, tuvo un evento, tuvo un estimulo pero el
nombre del estado no cambio entonces yo represento eso con una flecha que vuelve al mismo estado
y el nombre del evento como conocemos si es necesario agregamos condición de guarda o alguna
acción.
Estado compuesto y subestado
Un subestado es un estado que esta anidado dentro de otro. Cuando analizamos sistemas puede
ocurrir que un estado que identificamos, en forma interna, tenga otras condiciones u otras situaciones
Análisis de Sistema Resumen Nicolás Aguirre
a tener en cuenta y a eso lo vamos a llamar subestado. Vamos a empezar a trabajar con estructuras
anidadas dentro de un estado siempre hay un estado mayor que lo contiene y lo que identifiquemos
internamente como otros estados se denominan subestados.
Cuando nosotros tengamos un estado con subestados o con estados anidados estamos llamando a
eso estados compuestos, en el ejemplo que veíamos recién, un estado que tenga un solo nombre que
tiene una transición con su evento y pasa a otro estado destino es un estado simple, cuando el estado
que estamos analizando tiene subestados es un estado compuesto.
Nosotros estamos dentro de un estado origen conocido como estado 1, hay una transición y vamos a
graficar dándole un nombre al estado que va a ser el compuesto e internamente vamos a representar
sus subestados. Podemos ir representando dos o mas
subestados, si yo tengo un estado compuesto es porque
internamente tiene dos o mas subestados. La simbología
para representar internamente a sus subestados es la
misma notación que vimos recién. El estado se representa
ya sea estado, estado compuesto o subestado es un
recuadro con los bordes redondeados, con un nombre con
la notación como vimos hasta recién. Las transiciones
también se grafican como una flecha continua y vamos
siempre de un estado origen a un estado destino. Por cada
transición se le agrega el evento con la misma sintaxis, lleva
un nombre y puede tener condición de guarda y acciones. La línea discontinua no es necesaria
representarla. La línea discontinua no es necesario escribirla, sino que es para poder representar lo
que son los subestados.
Luego que ocurren esos estados anidados podemos continuar con otro estado destino de ese estado
compuesto que se grafica con los mismos elementos. A veces la transición puede llegar al borde del
estado compuesto, a veces la transición puede llegar completamente al primer estado del estado
compuesto internamente las transiciones pueden llegar a dos o mas estados y a la vez de la salida
puede salir del borde o de un estado en particular, eso dependerá de como son las transiciones, si yo
lo pongo al borde significa que esa entrada puede ir al estado 2 o al estado 3, si yo lo dirijo a la
transición que entra al estado 2 solamente estoy dando la condición que del estado 1 entra al
subestado 2 del estado compuesto. Esta salida sobre el borde significa que del estado 2 o del 3 puedo
pasar al estado 4, si yo graficaría el estado 3 la transición directa al estado cuatro, estoy indicando que
solo se puede pasar del estado 3 al estado 4 y del 2 no se puede pasar. Entonces como grafiquemos
la transición y hasta donde llega la flecha va a estar indicando las condicione dadas para el cambio de
estado y de que transiciones validas se van a permitir en ese diagrama y conforme el comportamiento
que va a tener el objeto que estamos representando.
Normalmente cuando uno va construyendo diagramas de estados va encontrando los estados que son
estados simples y va haciendo transiciones. A medida que vamos construyendo diagramas de estado
mas complejos vamos a ver que de un estado origen llegamos a dos o tres estados siguientes, que
son distintos destinos y esos tienen un comportamiento y continúan, entonces cuando estamos viendo
que hay transiciones que van a distintos estados o cuando estamos viendo que esos estados están
correspondiendo a un concepto mayor es donde empezamos a encontrar un estado compuesto y
vamos simplificando transiciones. Supóngase un estado inicial generar, pasamos a cuatro estados
siguientes con las mismas transiciones, con eventos, pero conceptualmente quiero representar que
estoy en proceso de elaborar algo, entonces yo puedo simplificar ese tipo de transiciones con estados
Análisis de Sistema Resumen Nicolás Aguirre
compuesto o subestados entonces permiten simplificar transiciones similares desde diferentes estados
agrupándolos es un estado compuesto. Este tipo de transiciones en función que llegan al borde o
cuando estén modeladas heredan todas las transiciones de los estados en los que están contenidos y
si el estado es compuesto tiene una transición determinada que es cunado el origen llega a uno en
particular, vamos a trabajar en función de como representemos si llega al borde del estado compuesto
o a uno en particular será el concepto y el análisis y la lectura de ese diagrama de como se comportan
los estados anidados o los subestados dentro del compuesto
Pueden existir distintas posibilidades de transiciones de ingreso y salida al estado compuesto y a sus
subestados.
Dentro de lo que son los estados compuestos hay una serie de conceptos a agregar como lo
siguientes: un estado compuesto puede tener subestados que se llaman concurrentes que estarían en
la categoría secuenciales u ortogonales y hay toda una consideración de los estados de historia, pero
no lo vamos a ver en detalle.
Relación con otros modelos
Por un lado, tenemos relación con el modelo de requerimientos, con los requerimientos globales, la
idea es que el requerimiento global me va a ir dando las distintas funciones que tendrá el sistema y yo
tengo que ir relacionando con toda la información que vamos a manejar con las clases y con los
detallados voy a ir teniendo el nombre de aquellas funciones que me van a colaborar con lo que me
va a producir los cambios de estado. Este crecimiento de llegar al diagrama de estados es porque ya
venimos creando el modelo de requerimientos y hemos identificado todo el listado de requerimientos,
ya desde ahí nosotros empezamos a visualizar situaciones que vamos a tener que generar, si tenemos
generar presupuesto de muebles, registrar aceptación de presupuesto del cliente, registrar seña de
presupuesto, ese tipo de funciones detalladas me están dando una pauta de situaciones que voy a
tener que considerar en el estado de alguien, en este caso estoy identificando la clase y el estado de
esos objetos.
Como el modelo de requerimiento, los funcionales es lo que me permite construir el modelo de casos
de uso habrá casos de usos identificados a partir de esos funcionales que son los que concretamente
voy a considerar como estímulos que va a producir el cambio de estado y por otro lado en la descripción
del caso de uso va a tener que tener algún paso en algún espacio en todo lo que voy describiendo
donde yo indique esa situación cambio de estado. Cuando vamos encontrando casos de uso los vamos
a considerar a partir de sus requerimientos funcionales detallados. Cuando vamos describiendo los
casos de uso en ese trabajo del paso a paso de todos los escenarios, de los destinos caminos,
considerando todo lo visto de los patrones, en algún paso de esa descripción debe estar indicado la
situación del cambio de estado, tenemos que identificar y explicitar esa situación del estado. Tenemos
sumad a esto prototipos de interfaz que pueden llegar a tener, por ejemplo, si es confirmar el
presupuesto, estamos indicando el estado que llevamos o si tenemos un prototipo de consultas como
consultar presupuesto podemos ver los presupuestos generados y así en base de lo que vamos
modelando el prototipo también va visualizando nombres de estado.
Todo el modelado de negocio nos dio conocimiento del diagrama con BPMN, y en ese diagrama
cuando vamos detectando formularios y todos los objetos de datos ya desde el vamos podemos llegar
a tener estados de esos formularios que son candidatos a tener un diagrama de estado y las distintas
actividades van a ser los estímulos que van a provocar el cambio de estado.
Análisis de Sistema Resumen Nicolás Aguirre
En el diagrama de clases los eventos que vamos a ir escribiendo nosotros en las transiciones se
corresponden con las responsabilidades de una clase, por eso tiene la misma notación. Nosotros
tenemos objetos, una clase es un conjunto de objetos, la máquina de estado modela el comportamiento
de esos objetos, el ciclo de vida, concretamente el objeto cuando se crea tiene en su naturaleza estado
comportamiento e identidad. Cuando hablábamos del estado del objeto en su naturaleza dijimos que
se define como el conjunto de las propiedades de ese objeto mas los valores que asumen esas
propiedades.
Cuando modelamos el comportamiento de ese objeto que conforma la clase, dentro del
comportamiento vamos a tener que considerar los eventos que provocan esos cambios de estado
porque justamente son los cambios de estado de un objeto y como el diagrama de estado muestra el
comportamiento de un objeto nosotros vamos a escribir en el espacio del diagrama de clases, en la
sección de responsabilidades teniendo una correspondencia directa.
Van a haber diagramas de interacción, de comunicación y de secuencia que son diagramas de
interacción donde van a ir modelando la correspondencia y como va cambiando de estado un objeto.
Una maquina de estado es un diagrama mu útil, simple de construir pero que esta conectado y
consistente con todos los otros modelos y diagramas, especificaciones que venimos haciendo.

Trazabilidad con otros modelos

Nosotros cuando tenemos, aparte de todas esas correspondencias que vimos, siempre tiene que estar
relacionado con el diagrama de clases y el diagrama de casos de uso. Cada vez que hablemos de un
diagrama de estado con quien debe tener correspondencia o trazabilidad los modelos con los cuales
se corresponden son el modelo de objetos de dominio en relación al diagrama de cases, el modelo de
casos de uso en relación a los casos de uso y el modelo de análisis en la realización de los casos de
uso.
Análisis de Sistema Resumen Nicolás Aguirre
Trazabilidad en relación al diagrama de clases
Todos los métodos que son los eventos de llamada que habíamos dicho que figuran en los diagramas
de estados, cada método o evento de llamada que figuran en el diagrama de estado y provocan el
cambio de estado deben estar presente en la definición de la clase. Hay dos lugares que deben tenerse
en cuenta: el evento como responsabilidad de la clase y a la vez la clase un atributo que diga estado,
atributo simple o de referencia, pero debe estar el estado mencionado como una propiedad de la clase,
sino estaríamos modelando estados de un objeto que no tiene un atributo que vaya guardando esa
información, ese valor de esa propiedad.
Debe existir un atributo estado primitivo o modelado mediante una clase, esto de estado simple o en
otra clase que diga estado del presupuesto. Cada evento y transición del diagrama de máquina de
estado, debe corresponderse con responsabilidades o métodos de la clase.

Este ejemplo es de la cuota de servicio, esta clase tiene una serie de atributos que tiene entre sus
atributos uno que puede ser un estado primitivo o simple o en otra clase modelado el estado (clases a
la derecha). Debe existir una clase que en sus atributos definidos contenga un atributo propiamente
que sea estado, ya sea como estado o como atributo simple o atributo primitivo o como atributo
modelado en un conjunto de clases para llevar su cambio de estado y demás.
Cada evento del estado debe estar como responsabilidad de esa clase. Aunque tenga mala calidad la
foto, en el diagrama de estado aparecen eventos como prescribir, registrar la baja, todos los eventos
escritos en su diagrama de estado deben estar como responsabilidades del diagrama de clase. Y a la
vez debe haber un atributo en la misma clase que este representando ese valor que le estamos dando
al estado.
Análisis de Sistema Resumen Nicolás Aguirre
Trazabilidad en relación a los casos de uso con diagrama de casos de uso
Para cada evento que vamos identificando debe existir al menos un caso de uso que se corresponda
con ese evento o con ese método y que provoca el cambio de estado.
Recordemos lo que es un caso de uso, van a ser fragmentos de funcionalidad que ejecutan una serie
de acciones, cumpliendo un objetivo y obtienen un resultado de valor para un actor. Eso significa que
un usuario accede a un sistema, ejecuta una función y obtiene un resultado. Si estamos ene le ejemplo
del presupuesto habrá un caso de uso que sea generar presupuesto a cliente, esa es la funcionalidad
o el fragmento de funcionalidad, ejecuta un conjunto de acciones busca un cliente, los precios de los
distintos muebles que quiere el cliente, calcula un total, da una fecha de vigencia y genera un
presupuesto entonces el estado de ese objeto presupuesto es generado.
Siempre debemos tener un estado y a la vez un caso de uso que comprenda una función que considere
el llegar a ese estado o el cambio de estado de un estado inicial a un estado siguiente. Habrá otra
funcionalidad cuando el presupuesto ya fue generado que será otro caso de uso que será registrar
respuesta de cliente o registrar aceptación de presupuesto. Cuando pienso ese caso de uso, entre su
conjunto de acciones, el fragmento de funcionalidad, busco un presupuesto en estad generado,
registro los datos de confirmación, calcula el porcentaje de seña, y lo cambia de estado cuando
confirma que fue aceptado el cambio de estado significa que va a pasar a aceptado. Siempre que
modelemos un diagrama de estados tenemos que ir encontrando los casos de uso que van provocando
ese cambio de estado.
De alguna forma hay una correspondencia directa para todas las transiciones encontradas con los
eventos con las funcionalidades reconocidas en el diagrama de casos de uso.
Debe existir al menos un caso de uso en relación a cada método que provoca un cambio de estado.
Al menos uno porque dependiendo del sistema puede haber distintos casos de uso que llegan a ese
estado en función a la cantidad de transiciones que tengamos. Debemos tener casos de uso que nos
permitan administrar todos los estados de la clase, del diagrama de estados y de la clase, por eso el
diagrama de clases y diagrama de casos de uso tienen la correspondencia que habíamos visto antes.
El análisis si lo hacemos bien, integral y consistente todos los diagramas se corresponden en algún
punto con alguna parte de otro diagrama y de allí vamos creando este sistema y cada uno le va dando
una vista diferente conformando todos los planos del sistema, el diagrama de clases muestra
estructura y comportamiento de este sistema que estamos modelando, el de casos de uso muestra las
funciones que el sistema va a tener, el diagrama de estado muestra apara algún conjunto de objetos
con distintos comportamiento para cada objeto el ciclo de vida de un objeto contenido en una clase
con funciones que ejecuta un caso de uso entonces vamos teniendo todos los hilos conductores
relacionados.
En la descripción del caso de uso debe existir un paso en donde se detalle ese cambio de estado.
Hacer esta comprobación nos puede llevar a descubrir esto que es lo importante, talvez vamos
modelando el diagrama de estados y de repente encontramos un estado y cuando buscamos la
funcionalidad o el caso de uso que provoca el cambio de estado no esta definido. A veces un diagrama
de estado permite encontrar nuevos casos de uso que no nos dimos cuenta cuando fuimos pensando
en el primer conjunto de funcionalidades y nos damos cuenta a posterior cuando vamos pensando en
los estados que estamos entrando de forma mas profunda a modelar ese sistema.
Si el estado sirve y es necesario contemplarlo vuelvo al diagrama de casos de uso y completo, agrego
el caso de uso logrando la consistencia. Si ese estado no tiene un caso de uso tendré que repensarlo
Análisis de Sistema Resumen Nicolás Aguirre
a ver si el estado es valido de considerar o no. Entonces uno va haciendo este proceso que es iterativo
e incremental, vamos avanzando en el detalle y vamos refinando los modelos corrigiéndolos, el
resultado final es una iteración completa.

En algún paso que estamos registrando la prescripción de la cuota que es cuando la cuota ya se
desiste de cobrarla en algún punto donde se confirma esa acción se aclara en forma específica: “El
sistema registra la prescripción con los siguientes datos: fecha de prescripción, nro. de resolución y
actualiza el estado de la cuota como descripta” En alguna forma el paso de una descripción tiene que
tener correspondencia con el cambio de estado y el caso de uso con el evento que cambia el estado
y el evento propiamente con el diagrama de clases para ese objeto que muestre la responsabilidad de
la clase.
Lo mismo pasa en generar la intimación de cuotas, en algún paso el sistema actualiza el estado de la
cuota.
Documento de especificación de Requisitos
A partir de la información recopilada en la elicitación vamos a realizar la especificación de
requerimientos obteniendo como resultado un documento cuya importancia va a servir a modo de
contrato entre nosotros y el cliente. Nos va a servir porque nosotros vamos a describir todo el
comportamiento que estamos definiendo del sistema que estamos proponiendo y todo ese
comportamiento funcional deseado de software con una serie de aspectos, de algunas restricciones
que tenemos que tener en cuenta que son ese listado de requerimientos no funcionales. A lo que es
requerimientos funcionales nosotros vamos a crear un diagrama de caos de uso, todo el modelo de
casos de uso con su descripciones y prototipos que va a formar parte de este documento y también
vamos a hacer el diagrama de clases que va a ser parte de este documento y vamos a definir algunos
Análisis de Sistema Resumen Nicolás Aguirre
aspectos no funcionales. Todo eso va a conformar este documento de especificación de
requerimientos de software.
Las siguientes son las palabras que comprenden a este documento:
Especificación: es una actividad o un proceso que va a describir en forma completa, precisa y
verificable toda la propuesta que estamos haciendo y los requisitos funcionales y no funcionales.
Requisitos o requerimientos: es el conjunto de todas las características del sistema que estamos
realizando o la descripción de los mismos con todos los servicios y restricciones a considerar.
Software: es el conjunto de programas y código, procedimientos y documentación asociada a la
operación de un sistema informático.
Otra forma de definir el ERS puede ser:
Este documento esta establecido en un estándar, existe una institución que es la IEE que establece
definiciones y estandariza conceptos, definiendo el estándar 830 donde describe la definición de una
ERS y la estructura que debe tener este documento, luego nos basamos en esos lineamientos de esa
estructura que propone el estándar y lo adaptamos a un proyecto en particular con las características
que tenga el mismo. La definición es: “es la documentación que escribe en forma detallada y completa
los requisitos esenciales (funciones, rendimiento, diseño, restricciones y atributos) de software y de
sus interfaces externas del sistema en relación a su entorno, incluyendo la comunicación con otros
softwares, usuarios humanos, hardware del sistema y comunicación con otros componentes de
hardware”
En su definición dice que va a describir una forma completa y bien detallada y precisa todos los
requisitos o requerimientos que este sistema va a comprender. Aspectos funcionales y aspectos no
funcionales.
Propósitos de la ERS

Comunicación entre clientes, usuarios, analistas y diseñadores

La ERS va a servir a modo de contrato, lo que vayamos escribiendo y especificando en este documento
va a servir de comunicación con el cliente. Vamos a estar detallando ahí que funciones va a tener el
sistema, primero como un listado de requerimientos funcionales y luego vamos a encontrar casos de
uso y los vamos a describir. En esa descripción nosotros le estamos comunicando al cliente cual va a
ser la lógica de esos procesos y que funciones va a ejecutar el sistema.
Análisis de Sistema Resumen Nicolás Aguirre
Esta comunicación justamente sirve si esta bien descripta, completa y detallada le sirve al cliente para
saber todo lo que, si va a hacer el sistema, sin ambigüedad, sin dudas y que es aquello que lo que no
esta descrito hay un espacio donde uno indica en una ERS lo que no incluye el sistema, de alguna
forma sirve como acuerdo entre las partes, por eso ese concepto de forma de contrato.
Fuera de esto, existe aparte un documento de gestión de proyectos, un presupuesto que va a
acompañar la propuesta que lo hace desde la parte de las actividades de sombrillas y toda la gestión
de un líder de proyecto. Pero cuando nosotros estamos documentados nuestra tarea mas operativa
de análisis funcional y esta descripción. Todo lo que este descripto allí, todo lo que haga el sistema,
los prototipos, los datos que estén incluidos van a servir a modo de acuerdo con el cliente diciendo:
“esto es lo que hace el sistema y esto es lo que se propone” por eso sirve de comunicación entre
ambas partes.
Entones este seria nuestro primer propósito.
Soporte a las actividades de prueba del sistema
En nuestro desarrollo de sistema tenemos una tarea de análisis de requisitos y análisis funcional, luego
tenemos toda una tarea de diseño donde le agregamos algunos aspectos de implementación y algunos
detalles de estas consideraciones de restricciones de los requerimientos no funcionales, después
viene una etapa de codificación, programación y por ultimo una etapa de prueba. Este propósito esta
referido a esta etapa de prueba, a lo que se conoce como testing, porque todo lo que nosotros
especificamos pasa por el diseño, por la implementación o por la codificación y luego hay alguien que
trata de verificar de esto que esta descripto y propuesto en este documento y esto que esta
desarrollado a ver si realmente coincide y si cumplen.
Entonces la ERS le sirve a los de testing a saber que es lo que se esta proponiendo y luego ver el
equipo de programación que programo para ver si coincide. Esa es la idea de este propósito que
propone que una ERS hace de soporte a esas actividades de testing del sistema.
Control de evolución del sistema
Todo sistema que estoy proponiendo, vamos trabajando, tiene un proceso iterativo, pero siempre va a
ir evolucionando o creciendo, entonces una ERS permite controlar toda esa evolución del sistema
porque yo voy desarrollando un sistema, voy acordando con el cliente si es lo que quiere y haciendo
os ajustes que necesita. Pero a veces surge en esto que yo le voy mostrando al cliente y voy trabajando
la propuesta que de repente propone o necesita nuevas cosas, si es algo nuevo eso es el parte de un
nuevo acuerdo o se puede agregar a la ERS lo tendremos que trabajar con el líder del proyecto, pero
no implica que cada cosa nueva que pide el cliente es obligación del equipo de sistema incorporarlo,
dependerá de los tiempos acordados en algún cronograma, del presupuesto, y del alcance definido
con el cliente.
Una ERS si dice: “Todo esto vamos a hacer”, el cliente puede lograr mejoras, por ejemplo, decir que
este dato está bien o esta pantalla me gustaría de tal forma, eso es válido, pero si agrega nueva
funciones eso esta fuera de esto que estamos haciendo por tanto será parte de una nueva iteración,
o un nuevo incremento o un nuevo acuerdo. Porque si no nunca terminaríamos de hacer un sistema
porque siempre el cliente necesita estas funciones y otras mas entonces uno acuerda estas propuestas
de sistemas con un objetivo y un alcance de allí que uno plantee este listado de requerimientos
funcionales y no funcionales. Todo lo otro agregado de nuevas funciones necesito una gestión de
proyecto, un líder que vaya acordando esos otros incrementos del sistema con nuevo acuerdos,
presupuestos y tiempos.
Análisis de Sistema Resumen Nicolás Aguirre
En función de esto y como resultado más su definición la ERS va a servir como la definición única de
lo que el software debe hacer, todo lo que este descripto allí con las funciones estamos describiendo
en detalle el alcance del sistema más las restricciones a considerar, este concepto de requerimientos
funcionales y no funcionales. Resultando este modo como contrato entre clientes y el equipo de
sistema.
Qué debe incluir una ERS
El documento puede incluir los requerimientos del usuario y los requerimientos del sistema. Uno puede
escribir los requerimientos con dos miradas: el mismo requerimiento primero lo escribe desde el
vocabulario y la vista del usuario, son como declaraciones generales de lo que el cliente estaría
necesitando y luego de los requerimientos del sistema tomo cada uno de esos requerimientos del
usuario y le doy una descripción mas detallada con una mirada mas de sistemas de la funcionalidad
de esto que estoy proponiendo que este sistema debe cubrir y va a proporcionar. En una ERS se
podría escribir de estas dos formas:

Por otro lado, la forma de expresar estos requerimientos o requisitos se podrían escribir de este modo:
requerimientos de comportamiento y requerimientos de no comportamiento. Concretamente se
corresponden con los requerimientos funcionales y no funcionales.
Una ERS puede contener los requerimientos del sistema y del usuario o escrito de otra forma,
requerimientos de comportamiento y de no comportamiento. De allí este concepto de los funcionales
que son todas las funciones que el sistema debe cumplir con su escritura global y detallada y todos
aquellos requerimientos de no comportamiento que son los requerimientos no funcionales que
atienden a las restricciones de hardware, de arquitectura, de implementación, de diseño, de
normativas, etc.
Análisis de Sistema Resumen Nicolás Aguirre
Que no debe incluirse en una ERS
Cuando vimos las cuatro P definimos: Proceso, producto, personas y proyecto. Cuando uno describe
una ERS esta describiendo el producto, todo lo que va a hacer el sistema y la definición completa,
pero no describe aspectos del proyecto. No debe incluirse
Requerimientos del proyecto: planificación general y coordinación de los distintos recursos que me van
a servir en un tiempo para el desarrollo de un sistema. Habla de la gestión de proyecto y de las
actividades sombrilla. Todos esos requerimientos del proyecto no deben incluirse y escribirse en una
ERS. No incluye aspectos de necesidades del proyecto general. Por ello no debe definirse:
Cronogramas, ni fecha de inicio y fin de actividades, ni fases, ni costos, ni recursos a utilizar y personal
de apoyo. Porque todo eso es un documento que va a acompañar a la ERS y que es la documentación
que acompaña al proyecto
Diseños del software: nosotros planteamos requerimientos funcionales y no funcionales. No debe
incluir una ERS el como le va a dar tratamiento a esos requerimientos no funcionales y funcionales
que es justamente la etapa en el diseño que viene posterior a una ERS. La ERS es la especificación
de requisitos, es el trabajo de análisis de requisitos, entonces no se incluye como ya que análisis es el
que y el diseño es el como se implementa ese sistema. Todas esas características de diseño no deben
incluirse en una ERS.
Planes de aseguramiento del producto: se refiere a todos esos aspectos de calidad, todo lo que tenga
que ver con calidad del software no estaría escrito en la ERS. Va a ser también otra área de trabajo, y
otro documento que va a acompañar.
Estos 3 ítems no estarían incluidos en una ERS y van a conformar parte de otros documentos de la
etapa de diseño, gestión del proyecto y gestión de calidad.
Usuarios del documento de requerimientos
Son 5 en total que serían nuestros usuarios del documento, aquellos que van a hacer uso y lectura de
este.
Clientes del sistema: toda esta especificación el cliente la puede leer, le va a servir para la definición
de los requerimientos, cuando lo va leyendo va verificando si va cubriendo sus necesidades y nos dará
un feedback de aquellos cambios para ajustar a los requerimientos según lo que el necesita.
Administradores o lideres del proyecto: va a servirles estos documentos para poder gestionar toda la
verificación, los tiempos de desarrollo del sistema y todo el presupuesto que acompaña a esto y
también los recursos.
Ingenieros de sistemas y analistas funcionales: va a servir para que quede en claro todo lo que debe
comprender el sistema y todos los modelos van a graficar visualmente todo lo que el sistema va a
tener en consideración.
Ingenieros de pruebas del sistema: les va a servir para poder desarrollar los distintos casos de prueba
y de esta forma poder validar el sistema
Ingenieros de mantenimiento del sistema: utilizaran estos requerimientos para poder comprender el
sistema y en el tiempo hacer el mantenimiento del mismo y entender la relación entre sus partes.
Análisis de Sistema Resumen Nicolás Aguirre
Características de una buena ERS
Una buena ERS debe considerar las siguientes características:

Debe ser completa donde todos los requerimientos detectados deben estar identificados, debe ser
consistente, inequívoca el tema de que no sea ambigua ni que me este dando una descripción que no
sea clara, que sea correcta porque debe abarcar los requerimientos que corresponden, trazable que
significa que pueda hacer trazabilidad entre lo que encontré como requerimiento funcional entre el
caso de uso que me cuenta la historia, entre la descripción y el prototipo de ese caso de uso de ese
requerimiento, ya que trazabilidad es una línea que vaya relacionando las distintas partes. Que pueda
ser priorizable significa que yo tengo un listado de requerimientos que yo lo pueda priorizar, no se
puede empezar todo junto en un inicio, sino que yo voy a tener que darles prioridad y hay un primer
ciclo con un conjunto de requerimiento donde hare su detalle, su implementación y demás e iré
trabajando por prioridad todo eso. Por otro lado, debe ser modificable en que se pueda modificar y
mantener actualizada dentro de lo que corresponde como las mejoras que me va dando como
devolución el cliente y por otro lado verificar que yo pueda a eso que estoy describiendo, que estoy
especificando alguna formad e poderlo verificar y esto tiene que ver con el área de testing que pueda
verificar si se cubre el mismo y se cumple con la propuesta y es acorde con la necesidad del cliente.
Todas estas características están en el estándar de la IEEE.
Estructura de una ERS
La IEEE en su estándar 830 propone una estructura que comprende los siguientes ítems
1. Introducción 2. Descripción General 3. Requisitos Específicos 4. Apéndices | Índice
Los 3 primeros son los contundentes que tienen todo el contenido.
Análisis de Sistema Resumen Nicolás Aguirre
1. Introducción
Esta introducción tiene 5 subtítulos.
Por un lado, el propósito donde se delinea el propósito de la ERS y se especifica a quien se dirige. Es
un párrafo genérico diciendo el propósito del documento formulado en una expresión narrativa y
dirigido a los futuros usuarios, clientes, uno va explicando ahí para quien estaría dirigido.
La ERS debe tener un alcance o ámbito del sistema donde yo ahí voy a indicar los productos de
software que estoy proponiendo y lo que va a hacer el sistema y lo que no va a hacer el sistema.
Entonces concretamente vamos a tener el objetivo del sistema de información y una expresión a modo
de alcance, pero narrativo diciendo: “el sistema va a comprender” y yo describo un poquito sin llegar
a escribir como requerimientos funcionales el listado de todo el detalle que va a abarcar el sistema y
en otro párrafo lo que no va a estar incluido en el sistema. De esta forma delimito el alcance del mismo,
por eso si vamos viendo sirve de acuerdo con el cliente, el cliente lee esta sección y entiende que
vamos a hacer y que queda fuera del alcance y de esa forma podemos acordar con el sobre que
estamos proponiendo.
Después vienen las definiciones, acrónimos, siglas y abreviaturas, es como un diccionario de datos,
un glosario de términos, de las definiciones y terminologías que usamos en el documento.
Hay una sección de referencia que sirve como una lista de los documentos referenciados, a veces el
cliente me entrega un antecedente como una ley que yo tengo que tener en cuenta entonces acá en
referencia podría haber y escribir las referencias de la ley y si esta en archivos con un documento y si
esta impreso, una serie de referencias de antecedentes de lo que ye he investigado en su momento
en la elicitación y el cliente me entrego como información.
Un ítem visión global o general del documento que es un párrafo que formaliza esa ERS como esta y
todas las secciones que vienen a continuación mas o menos que contienen (secciones 2,3,4) entonces
es como una forma de referir.
Por eso esta sección completa de introducción me da el panorama en forma general de hacia donde
va la propuesta del sistema.
2. Descripción General
Esta a su vez tiene también varios subítems o títulos.
Por un lado, lo que es la perspectiva del producto es este producto que yo estoy realizando si es
independiente si va a tener relación con otros, si se debe conectar con otros. Es una referencia donde
analizo los aspectos: “Relación con otros productos o proyectos, Productos independientes,
Componentes de un sistema o de un proyecto, Hardware y equipamiento periférico”. Supóngase que
este sistema, estamos haciendo un sistema de ventas, ya existe un sistema de compra y entonces
indicare que este producto va a tener relación con el sistema actor de compras o directamente estoy
haciendo un sistema integral y completo de un producto independiente que no va a tener relación con
los otros sistemas que tengan esa organización si ese es el acuerdo con el cliente, todo dependerá de
eso.
Después viene una sección de funciones del producto es el resumen de todas las funciones que
ejecutara el software con algún diagrama si es necesario que yo podría establecer allí, no establece
requerimiento especifico. Si nos damos cuenta en este aspecto podría escribir ahí un poco los
requerimientos funcionales globales, voy dando una perspectiva de como va a funcionar el sistema.
Análisis de Sistema Resumen Nicolás Aguirre
Después tenemos otro subtitulo características de los usuarios. Este futuro usuario vamos a tener que
conocer el nivel del conocimiento que tienen del sistema, que tipo de uso harán del mismo, cuantas
horas tendrán que hacer uso del sistema y todo eso va conformando una descripción de las
características de esos usuarios.
Tenemos el ítem de limitaciones generales y restricciones. En este espacio nos va a servir todo lo que
sea restricción de tipo limitaciones, políticas regulatorias, aspectos de hardware, interfaces con otras
aplicaciones, aspectos de diseños. Si vamos viendo un poquito sería todos los requerimientos no
funcionales irían identificados acá.
El ítem siguiente es el supuestos y dependencia. Esto tiene que ver con que la propuesta que estamos
haciendo hay una serie de elementos dependientes de otras áreas, de otros recursos, de otros
sistemas entonces yo tengo que especificar, o a veces hay dependencias en relación a que yo puedo
usar esta información, pero quien carga esos datos están en otor sistema. Son todos aspectos que me
van a hacer que mi propuesta este dependiendo de lo que me propone o lo que va a consumir de otros
sistemas o lo que va a proveer como recurso el cliente. Si el cliente en un sistema de gestión comercial
y quiere que yo pueda crear un sistema que pueda cobrar con tarjeta conectado a un posnet, defino
como supuesto que el cliente es responsable de disponer de ese hardware que es el posnet porque el
posnet se lo dan en los clientes que tienen negocios acordados con las tarjetas de crédito. No depende
de mi como equipo de sistema disponer de ese recurso, entonces hay situaciones donde va a existir
el registrar el cobro con tarjeta, pero el supuesto explicaría que el cliente va a disponer del recurso que
es el posnet con el dispositivo apropiado para que se pueda ejecutar esa función, entonces habla de
ese tipo de supuestos y dependencias. Es importante que estén escritos porque va justamente
delimitando que va a hacer el sistema y de que dependo de los otros elementos.
El otor ítem es requerimientos futuros. Esto justamente es lo que el cliente puede ir proponiendo o le
surge como situación yo podría decir: “bueno, este sistema el alance dije que comprende y a futuro
podría tener otro sistema, otras funciones como agregar la parte contable, en esta primera versión del
sistema voy a hacer web y a futuro un entorno mobile para que el cliente pueda consultar el estado de
su pedido”. Son situaciones que yo voy definiendo ahora que es lo que quiere el cliente, pero en esta
propuesta no va a estar incluido, esto es la escalabilidad del sistema, que seria como va a ir creciendo,
pero yo al sistema lo voy a ir desarrollando por partes y a veces tengo un acuerdo con un programa y
un presupuesto de la primera y luego el sistema va a ir escalando en sus dimensiones, va a ir creciendo
y lo defino acá-
3. Requisitos específicos o requerimientos específicos
Esta sección contiene el detalle completo de la propuesta, tendría toda la especificación y todos estos
modelos y diagramas que vimos seria el espacio para indicar acá.
Tenemos una primera sección conocida como requisitos de interfaz externa estos justamente serán
en función de este sistema en relación con otros sistemas distintas interfaces que deba tener
conectada. Cuando mi sistema va a estar teniendo relación con otros sistemas a veces yo tengo vistas
o tengo un web service, es decir, que accedo, me da información y este sistema consume información
y hace algo mas o a veces este sistema debe proveer de información a otro sistema después de hacer
un proceso. Supónganse ese sistema hace toda la gestión de pedidos y le da a otro sistema que es
de finanzas los resultados de la factura general, entonces esta sección de requisitos e interfaz externa
estaría estableciendo esa serie de ítems. Por ejemplo, una ERS como este definida y que detalles
tenga a veces se define a veces no.
Análisis de Sistema Resumen Nicolás Aguirre
Otra sección es la de requisitos funcionales. Lo escribe de esta forma.
En este caso partiríamos de los requerimientos funcionales
del listado que esta descripto en una sección anterior o los
detallamos acá y vendría todo el modelado de los casos de
uso, con los casos de uso que comprende cada
requerimiento, con una descripción y con el prototipo. El
estándar queda genérico, no se pega a una metodología
particular y nosotros adaptamos esta descripción de
requerimientos funcionales a lo que la metodología que se
está utilizando en el mercado usamos como especificación.

Otra sección es requisitos de rendimiento de desempeño y la sección requerimientos de bases de

datos son todas aspectos de requerimientos no funcionales que hacen a estos detalles, pero
discriminados, lo de rendimiento de desempeño de la capacidad del procesador, velocidad de
procesamiento y requerimiento de bases de datos aspectos de backup resguardo y demás. Es una
forma de ir discriminando los requerimientos no funcionales en estos títulos.
Otra sección es la de restricciones de diseño. Acá en esta parte también estaría considerando el
cumplimiento de estándares y las limitaciones de hardware. De todos los no funcionales como que el
estándar los va organizando u agrupando en distintos subtítulos.
Otra sección es la de atributos del sistema y de calidad. Acá van aspectos de seguridad, fiabilidad,
disponibilidad, portabilidad, manteamiento, los requerimientos no funcionales que hagan a este
aspecto
Otra sección es la de otros requisitos. Relacionada con los aspectos de base de datos, operaciones y
adaptación de situación.
Todos estos últimos ítems, son todos los requerimientos no funcionales discriminados en esta
clasificación que propone el estándar.
4. Apéndices
Comprende toda otra información que nosotros necesitemos adjuntar a esta especificación, como un
diagrama complementario, un diagrama de estado, un diseño de salida impresa que va a tener un
reporte entonces yo hago el diseño de salida, todo lo que sea necesaria anexar. Si hay algún requisitos
funcional que para una carga de datos utiliza un formulario preestablecido que el negocio tiene,
entonces el diseño de ese formulario que ese negocio utiliza podría también agregarlo en un apéndice
como el formato para que yo tenga cual es el formato previo del cual me servirá donde esta registrada
la información de una solicitud de inscripción para un programa es lo que me va a servir para escanear
un prototipo un registro de una solicitud o algo.
Se agrega un índice.
Adjunto un cuadro resumen de la estructura de la ERS
Análisis de Sistema Resumen Nicolás Aguirre

Uso de la ERS
El nivel de detalle que puede incluir ese documento puede llegar a tener un enfoque evolutivo,
habiendo aspectos que pueden dejarse planteados y justamente después permite ampliar eso y va a
ir evolucionando a una mayor especificación mientras contenga la parte funcional bien descripta. Esa
descripción de un caso de uso puede hacerse de forma mas general sin la plantilla entonces hay cosas
que uno podría dejar planteados identificados, pero con un nivel de especificación que no tenga tanto
detalle y en otros casos puede estar con un
detalle bien especifico porque si no esta bien
claras y descriptas podrías tener dudas o
ambigüedad o falta de precisión cuando
pasemos a las etapas siguientes.
Si no esta bien detallado y el equipo de sistema
también trabaja con algún grupo externo a
veces ocurre lo siguiente; el análisis funcional y
la programación otro equipo que es una
consultora que esta tercerizada, en función de
como especifique y que nivel de detalle si el
equipo no trabaja integrado o son equipos de empresas diferentes a menor especificación mayor
variedad en lo que va a ser el resultado, entonces en función de eso se necesitan descripciones bien
detalladas o no en las características anteriormente mencionadas.
Análisis de Sistema Resumen Nicolás Aguirre
Unidad 7: Validación de Requerimientos

Una vez que adquirí el conocimiento y cree toda una especificación concreta no termina ahí el proceso,
sino que debo validar con el cliente para ver si lo que yo estoy proponiendo es acorde a lo que el esta
necesitando. Esta misma especificación crea un documento que es un modelo de requerimiento que
es la entrada a la tarea de validación y que va a tener esta ida y vuelta con el usuario, va a mostrar
una serie de modelos para que valide y va a tener una devolución del usuario y de ahí se produce este
circuito reiterativo de que los resultados de la validación son también una entrada de la especificación
en donde se ajustara lo que sea necesario, puede disparar necesidad de mayor conocimiento de
adquirir mas información desarrollando nuevas preguntas, actualizar el modelo, volverlo a validar hasta
que en algún momento queda estable la propuesta validada por el cliente. Luego viene el diseño que
le agrega la parte del cómo y por ultimo pasa a la programación entonces la idea de esta tarea es de
ir validando la propuesta que se está especificando todavía no se ha codificado nada.
Concepto
Esta actividad lo que va a tratar de comprobar es que los requerimientos que yo he especificado en
ese detalle sean consistentes, estén completos y sean veraces, que estén cubriendo lo que necesita
el cliente. La validación trata de mostrar que los requerimientos especificados realmente definen el
sistema que el cliente desea y necesita. Porque a veces ocurre y es normal que yo entiendo que es
algo que quiere el cliente, armo una propuesta y cuando se la voy mostrando, no he captado o el no
se supo expresar de forma completa y uno va alineando propuesta y necesidad para que sea lo mismo
y complete la especificación del sistema con las necesidades de ese cliente. Finalmente, este proceso
de control lo que busca es asegurar que el software que se esta proponiendo cumple en su
especificación lo que debe describir y satisface esas necesidades del usuario.
Importancia de la validación
Este proceso se nutre de los anteriores y realiza la integración y valida esto que tenemos que certificar
que cubrimos los requerimientos del cliente. Es normal y es lógico que se descubran errores o
diferencias entre lo que esta especificado y lo que quiere el cliente, entonces hay un tiempo de ajustar
lo que sería la modificación de la ERS para corregir esas diferencias y dejar una propuesta consistente.
El tema es que, si nosotros no encontramos esas diferencias a esos errores en esta instancia del
sistema y dejamos que avance , se pasa al diseño, después a la programación y mientras mas tarde
se detecten esas diferencias y esos errores mayores serán los costos debido al retrabajo y aquello
que tenemos que modificar de la propuesta del sistema. Mientras la validación este hecha en su mejor
Análisis de Sistema Resumen Nicolás Aguirre
forma al inicio del proyecto que es cuando estoy especificando voy a disminuir los costos de lo que
significa que encuentre esos errores o esas diferencias cuando mas avanzado esta el proyecto.
Costos por errores en los requerimientos

Este cuadro va marcando como en las distintas etapas del desarrollo de un sistema mientras mas
temprano del desarrollo del sistema detecte esas diferencias y haga ajustes es menor el costo,
conforme avance el desarrollo del sistema mientras mas avanzada este en sus distintas actividades y
etapas mayor será el costo de los ajustes y modificaciones. Entonces por eso es importante la
validación.
Propósitos de la validación
Certifica la consistencia del modelo, de lo que yo estoy proponiendo de estos requerimientos con lo
que espera el cliente y ese futuro usuario.
Por otro lado, es necesario asegurar que el análisis realizado en los requerimientos, toda la
especificación en la propuesta y los resultados obtenidos de la etapa de especificación sean correctos
o me permitan detectar esas inconsistencias o errores y corregirlos.
Y también para evitar esos costos innecesarios por el riesgo de implementar una mala especiación no
validada.
Entonces la validación implica un trabajo con el cliente que es bueno mantenerlo en el desarrollo, no
es que yo detecto los requerimientos y hasta que no este programado no vuelvo al cliente la validación
sigue estando en este inicio de la propuesta del sistema cuando yo modelo la propuesta y es muy útil
porque cubre estos propósitos y busca minimizar los errores que se han detectado en forma posterior.
Validación y verificación
Hay un juego de palabras que dice:
Validación de requerimientos se usa en esta primera parte en donde lo que vamos a analizar como
pregunta es: ¿Estamos construyendo el producto correcto? Eso quiere decir que, si aquello que estoy
especificando, lo que encontré como requerimientos y específico si eso que estoy logrando especificar
que es el producto satisface los requerimientos del usuario. Si esa propuesta esta cubriendo esas
necesidades de usuario, por eso la pregunta es la que se había dicho antes. Eso seria si yo estoy
Análisis de Sistema Resumen Nicolás Aguirre
especificando, encontré requerimientos, describo una lógica, hago un prototipo, tengo que validar con
el cliente si es lo que el desea.
En cambio, la verificación si queremos darle una terminología propia a esto en sistemas la pregunta
asociada a la verificación va a ser: ¿Estamos construyendo correctamente el producto? Una vez que
pasamos las etapas de diseño y de programación cuando el equipo de prueba, los de testing, verifican
el sistema, comprueban que lo programado y lo que dice la descripción del caso de uso sea lo que el
software debe ejecutar.
La validación me dijo que este requerimiento y mi modelado es lo que el cliente quiere y luego pasan
las etapas de diseño, programación e implementación, y cuando vamos a la prueba el equipo de
prueba verifica si eso que hemos programado cumple con lo que dice la lógica descripta y lo que el
requerimiento debe hacer.
De allí este juego de términos y por eso usamos validación de requerimientos para validar si estamos
modelando la propuesta que cubre las necesidades y verificación una vez que esta programado si
hacemos las pruebas en el sistema lo comprobamos y vamos viendo si esta ejecutando el programa
lo que debe cubrir como necesidad y como descripción de esa funcionalidad y esa lógica.
Análisis de Sistema Resumen Nicolás Aguirre

El proceso de validación siempre se nutre de la especificación y de la elicitación primero donde debo

comprender y entender que necesita el usuario, voy analizando y definiendo la propuesta del sistema,
luego viene donde yo puedo aplicar la validación que no es una tarea aislada ya que necesita de ese
modelo creado y esa especificación en la actividad de especificación pero es muy importante que una
ve que aplico una técnica de validación hago los ajustes, aplico ,valúo los cambios según lo que el
cliente me observa y sigo en este ciclo hasta que voy validando la respuesta. Mientras mas tiempo
invierta en la validación reduzco o minimizo encontrar errores cuando mas avanzado esta el proyecto
o diferencias, entonces de esta forma voy logrando ir desarrollando una propuesta acorde a lo que
necesite el cliente.
Entradas del proceso
Todo modelo que yo creo esta sujeto a validación, lo que pasa es que hay modelos mas comprensibles
y otros muchos mas técnicos , pero por un lado el conocimiento sobre el dominio del problema debe
ser validados, talvez no le voy a mostrar un diagrama de clases pero yo tengo que validar los datos
que encontré ahí o el comportamiento del sistema pero es candidato a ser validado y la especificación
de requerimiento y prototipos de interfaz deben validarse que eso si es la descripción de la historia de
caso de uso y el prototipo de interfaz que es lo mas visual que puede llegar a chequear un cliente.
Actividades en la validación
Hay una interacción entre parte del equipo de sistema (los analistas) y los clientes y en esa charla uno
va entendiendo si lo que estamos entiendo nosotros como propuesta va siendo lo que el quiere, vamos
formulando la propuesta, vamos ajustándola y la vamos chequeando con ese cliente y de esa forma
se da la interacción entre los trabajos, la especificación y validación, que vamos y volvemos hasta que
logramos tener el conocimiento acabado y la propuesta acorde con esa necesidad. Esa validación es
un proceso iterativo, supongan que encontramos 100 casos de uso, no escribo los 100 casos de uso
Análisis de Sistema Resumen Nicolás Aguirre
primero y después voy el cliente, voy haciendo por iteraciones, ciclos, por conjuntos, entonces priorizo
esa lista tal vez trabajando 15 casos de uso haciendo descripción, prototipo luego hago una reunión
con el cliente y los voy validando y conforme voy cerrando o ajustando, modificando y dejando más
estable una parte de esa especificación puede ir avanzando con otro conjunto de casos de uso y de
esta forma el equipo de sistema que sigue la parte de diseño y programación trabaja con lo que ya
esta validado y consensuado y va caminando y empieza a programar y nosotros analistas seguimos
trabajando con la especificación de otra parte y hacemos este ciclo de elicitación, especificación y
validación hasta dejar también estable otra parte de casos de uso que le agregamos la parte de diseño
y de programación, de esa forma se va trabajando. Por eso esas actividades van en paralelo, se hacen
de forma conjunta todo eso.

Resultado final de la validación

Después de las distintas idas y vueltas es una ERS, un documento, un modelo de requerimientos a lo
que se construye como parte del proceso unificado se llama modelo de requerimiento, pero se hace
una especificación en línea y consistentes con las expectativas de los usuarios. De allí que sirve como
acuerdo esa ERS entre el cliente y el equipo de sistemas en lo que el sistema va hacer terminando
siendo un acuerdo, una forma de contrato o un compromiso. Es lo deseado, lo posible y lo factible.
Todo esto que estamos modelando es porque paso este análisis de prefactibilidad que es validar si es
factible la propuesta que estoy haciendo con un análisis técnico, económico y operativo si es factible
de concretarse de que se logre con éxito esta propuesta y que no estoy haciendo una propuesta que
no tiene posibilidades de aplicación real.
Tipos de comprobaciones
Hay una serie de comprobaciones, una clasificación en
cinco tipos y una serie de técnicas. Los tipos de
comprobaciones que podemos hacer se clasifican en
esas cinco.
Análisis de Sistema Resumen Nicolás Aguirre
Comprobaciones de validez
La de validez esta referida a que nosotros tenemos diversos usuarios con diferentes necesidades,
cuando nosotros hagamos todo ese trabajo de elicitación, si estamos hablando de un gerente estamos
en un nivel directivo. Cuando estemos en un nivel operativo y hay 10 empleados de venta no se pueden
quedar con que haga la elicitación con uno, ya que se debe seleccionar una cantidad apropiada para
que me de la información suficiente cosa de extender a toda la población que va a estar afectada.
Vamos a tener que poder abarcar una cantidad suficiente de usuario para poder tener validadas las
necesidades, pero por otro lado diferenciar lo que son gustos propios de lo que es una necesidad
concreta de un sistema. Entonces esa es la comprobación de validez, vamos a tener que abarcar un
conjunto de usuarios y tendremos que discriminar gustos propios de lo que el sistema realmente
necesite.
Comprobaciones de consistencia
La consistencia es cuestión de las contradicciones que pueda haber entre un requisito y otro. Mi listado
de funciones deben ser complementarias, no contradictorias, no puedo definir en un requerimiento una
función que va a hacer el sistema y luego otro requerimiento que se contrapone en algún punto
entonces debo tener consistente el listado de requerimientos.
Comprobaciones de integridad y completitud
Esta referido a que lo que esta descripto en los requerimientos incluya todas las funciones y
restricciones propuestas por el usuario, habla del listado completo de requerimientos funcionales y no
funcionales. Un poco esta se complementa con la anterior que sea consistente, que el listado no tenga
incongruencias y por otro lado ese listado este completo y sea integral.
Comprobaciones de realismo
La idea es que yo plantee un requerimiento y que toda su especificación sea posible de implementar
en consideración de la tecnología actual. Si yo tengo un sistema que solicita diversas funciones yo
primero tengo que ver si esos que estoy proponiendo es real, se puede implementar, los recursos que
tenga el negocio o lo que este dispuesto a invertir o la tecnología que actualmente tenga. Tengo que
plantear un requerimiento y toda su descripción acorde que se pueda implementar con los recursos ,
condiciones actuales de ese negocio y tecnología actual.
Verificabilidad
Habla de la verificabilidad de los requerimientos, que estén redactados de tal forma que luego cuando
lleguemos a la instancia de poder hacer las verificaciones , las pruebas de la programación realizada,
se pueda realizar. Esto es porque a veces en el tipo uno va escribiendo, especificando y a veces las
especificaciones son enredades, hay analistas que lo escribe de una forma donde se complica su
verificación. Entonces esto se refiere a que estén escritos de una forma en la cual puedan ser
verificados.
Técnicas de validación
Esas comprobaciones van a ser usadas en alguna de estas técnicas.
Existen 3 técnicas: las revisiones de requerimientos, creaciones de
prototipos y la generación de casos de prueba.
Análisis de Sistema Resumen Nicolás Aguirre
1. Revisión de requerimientos
La idea es que esto se hace en algunas ocasiones y tal vez al inicio con una primera versión de la
ERS cuando yo tengo un listado de requerimientos clasificados en funcionales, no funcionales
formando un grupo de revisores, una parte de equipos de sistemas y una parte de personal de cliente,
sirviendo para ir delimitando el alcance del sistema por eso se usa en primeras reuniones. Yo hago un
primer relevamiento con un nivel directivo o con un nivel superior de una organización, hago una o dos
entrevistas, planteo el listado de requerimientos funcionales y no funcionales y me reúno con esa parte
de personal del cliente para ir verificando si mas o menos estamos alineados. Si los sistemas son más
estándares como algo de comercialización son mas fácilmente detectables son más fácilmente
detectables los requerimientos, pero cuando los sistemas son muy diferentes o particulares, esas
primeras entrevistas tengo que verificar si lo que me va diciendo el cliente que necesita es mi primer
plantilla. Antes de ponerme de identificar casos de uso, diagrama de clases, tengo que validar un
primer listado de requerimientos. Esta técnica sirve en los primeros tiempos del inicio del proyecto o
de la propuesta del sistema.
2. Creación de prototipos
Es como una técnica por excelencia, que mas se utiliza, y la que mas entienden los clientes. Yo para
poder diseñar los prototipos he planteado el listado de requerimientos, creado el modelo de casos de
uso, he descripto y diseñado el prototipo. Un cliente entiende mas el diseño de las ventanas, de las
pantallas, contando las descripciones de casos de uso como lo entendí y también le cuento a través
de ese prototipo mi diagrama de clases entonces yo puedo ir validando los distintos modelos, pero me
valgo de los prototipos de interfaz para validar con el cliente si es lo que esta necesitando y si esta
cubriendo sus necesidades. Este prototipo va a ser como esa versión inicial del sistema , antes de
pasar a que este totalmente programado después del diseño.
La técnica de prototipado de interfaz es una técnica de representación donde yo dibujo una ventana
recordando el concepto de prototipo siendo un modelo a escala de lo real que me va a servir para
comprobar algo y en este caso el prototipo de la interfaz es un diseño de una ventana para que yo
pueda validar con el cliente si es más o menos lo que va entendiendo, lo que va cubriendo sus
necesidades y si resuelve sus problemas. Yo puedo llegar a hacer prototipos que tiene una utilidad,
se utilizan mucho durante todo este proceso de la ingeniería de requerimientos nacen desde la
especificación y se utilizan en la validación. Mas adelante en diseño se completan estos prototipos
agregándoles aspectos de la solución, de los requerimientos no funcionales y otro tipo de detalle que
tienen que ver con el avance para la implementación y también sirven en el proceso de prueba cuando
lleguemos después que este programado para poder hacer las distintas verificaciones del sistema con
ese prototipo que esta diseñada la tarea de especificación.
Hay dos tipos de prototipos, desechables o evolutivos. Estos que se llaman desechables son los que
bosquejamos en papel o que usamos algún software de representación, pero no tiene codificación por
detrás, sirven para el momento de validar con el cliente lo que yo estoy proponiendo y modelando. Los
evolutivos son aquellos que se crean, pero a partir de un lenguaje de programación, aunque sea la
maqueta que luego van a evolucionar a agregarle todo el código y que sean finalmente las pantallas
del sistemas.
Análisis de Sistema Resumen Nicolás Aguirre

En el caso de los evolutivos seria que voy a crear maquetas, pero están hechas con un lenguaje de
programación y ya por detrás tienen algo de código y depende quien lo este haciendo, como este
conformado el equipo, las características del proyecto si se puede hacer de esta forma o no. Una vez
que yo muestro, cambio o modifico esto ya luego continuo con mi lenguaje de programación y le agrego
a todo lo que yo estaba validando con ese cliente.

Obtenemos la especificación siempre primero,

construyo el prototipo, cuando aplico una técnica
de prototipo lo evalúo con el cliente y en esa
validación trabaja la parte del equipo de sistemas
con el cliente y ahí puede ocurrir que me haga
ajustes “no aceptado” me dice que mejorar, vuelvo
a corregir y construir el prototipo y esto tendrá un
ciclo hasta que me de el ok y tengo para que el
equipo siga trabajando en el desarrollo del
sistema.
Análisis de Sistema Resumen Nicolás Aguirre
3. Generación de casos de prueba
Esta técnica tiene algo de utilidad, pero la de prototipo es la de mayor uso, aunque es valida y se
puede utilizar en base a las características del proyecto. Yo escribo el comportamiento deseado del
sistema y me valgo del curso normal y de las alternativas y voy escribiendo que datos tendría que
ingresar y como podría validar para saber si es lo que el cliente quiere, entonces voy a crear casos de
prueba escribiendo distintos escenarios posibles con alguna serie de valores y luego yo valido con el
cliente si estoy entendiendo correctamente todos esos escenarios posibles y si tengo que ajustar algo,
tengo que mejorar u otra consideración tener en cuenta.
Cuando estamos diseñando escenarios, estos a veces obtiene cierta dificultad para poderlos
describirlos y encontrar significa desde el vamos que estamos hablando de requerimientos difíciles de
implementar, o los requerimientos son de mucha dificultad y debemos ver como mejorar la propuesta
o tenerlo en cuenta para darle una prioridad de alta complejidad o ver que se le puede reducir en
complejidad de alguna forma también el generar casos de pruebas me puede hacer una devolución
de que hay requerimientos muy complejos y darle un tratamiento lo mas optimo posible para que todo
pueda ser viable.
Unidad 8: El proceso unificado de desarrollo, el flujo de trabajo de requisitos
El proceso unificado de desarrollo de software PUD
Hay que recordar las 4 P: Proceso, proyecto, producto y persona. De allí se inició este concepto de
proceso de desarrollo de software.
Un proceso de desarrollo nos va a ayuda a nosotros como equipo de sistema para tener definido el
conjunto de actividades para llevar a cabo el desarrollo de un sistema o de un producto. Cuando se
trabaja en la construcción de un producto o sistema es importante ejecutar una serie de pasos
predecibles, es importante estar organizados y saber como debemos trabajar para optimizar tiempo,
recursos, costos, y todo el esfuerzo. Todo ese proceso unificado es como un mapa de carretera, que
me va guiando y nos ayuda como equipo a tener un resultado en el tiempo acordado y con una alta
calidad.
El proceso unificado nos va a servir como un mapa para desarrollar y ejecutar todas las tareas en este
proceso de software.
La definición de proceso de desarrollo de software es el conjunto completo de las actividades que
nosotros vamos a desarrollar con los métodos y fundamentos, ahí incorporamos una filosofía siempre
trabajando dentro de un paradigma, una serie de métodos y prácticas, todo lo que propone el lenguaje
de modelado estándar para crear los distintos diagramas y los distintos modelos y todo eso para
transformar los requisitos de un usuario, todo eso que son los requerimientos en un conjunto
consistente de artefactos que conforman un producto de software. El termino artefacto tiene que ver
con todos los resultados que se logran luego de la ejecución de un proceso.
Gráficamente
Análisis de Sistema Resumen Nicolás Aguirre
Capturar estos requisitos del usuario con esta tarea de elicitación incorporando y ejecutando el
conjunto de actividades para lograr este proceso de desarrollo, aplicar todas las técnicas y los
métodos, construir modelos dentro de un paradigma, ejecutar las actividades y lograr un resultado que
es el producto que es el sistema de software.
¿Qué es el PUD?
Es un entorno de proceso genérico, también denominado framework, metodología o un marco de
trabajo genérico. Es aplicable en distintos dominios, en distintas organizaciones con distintos rubros,
en distintas áreas de aplicación en distintos niveles de complejidad y dimensión que puede tener un
proyecto y es allí que, aunque las metodologías agiles vienen avanzado y hay una tendencia en el
mercado de que el proceso unificado deje de usarse durante todos sus años de vigencia y quien lo
sigue utilizando es porque es muy adaptable a una gran variedad de sistemas de software.
PUD y lenguaje unificado de modelado
El proceso unificado utiliza el lenguaje unificado de modelado para poder preparar todos los esquemas
de un sistema de software, todos los modelos y las vistas de este sistema y siempre trabajando con
todo lo que propone el paradigma orientado a objetos.
Características esenciales del PUD

1, Dirigido por casos de uso

El caso de uso es un fragmento de funcionalidad que un sistema va a ejecutar para cumplir con un
objetivo y va a proporcionar un resultado que le va a dar algo de valor a ese actor, a ese usuario porque
justamente necesita ejecutar ese caso de uso para obtener ese resultado. Los casos de uso están
asociados a los requisitos funcionales.
Que el proceso unificado este dirigido por casos de uso significa que nosotros cuando empezamos
nuestro conjunto de actividades para desarrollar un sistema empezamos por nuestra primera actividad
que va a ser encontrar los requerimientos a través de la elicitación clasificando en funcionales y no
funcionales. A partir de los requerimientos funcionales nosotros vamos a encontrar casos de uso y una
vez que encontramos casos de uso todo el proceso de desarrollo unificado PUD va a seguir las
distintas actividades siguiendo como hilo conductor o siguiendo los distintos modelos que va creando
esa mirada o esa identificación del caso de uso agregándole las especificaciones según la etapa en la
que avancemos que sea necesario agregar.
Análisis de Sistema Resumen Nicolás Aguirre
Dirigido por caso de uso quiere decir que le proceso de desarrollo sigue un hilo conductor, es decir,
avanza a través de una serie de flujos de trabajo que parten de la identificación de los casos de uso,
los cuales se especifican, diseñan implementan y prueban.
Partimos de identificar casos de uso y en las siguientes flujos de trabajo y etapas en las que vamos a
avanzar vamos a ir a partir de ese caso de uso agregándole algo más, definiendo algo más. En la
etapa de requisitos capturamos, definimos y validamos los casos de uso, es todo el proceso de
ingeniería de requerimientos.
Luego viene a partir de esos casos de uso identificados, un trabajo de análisis y diseño, un trabajo de
implementación que se llama la realización de casos de uso o realizar los casos de uso. Este proceso
termina con las pruebas donde a partir de los casos de uso voy a poder crear distintos escenarios para
poder verificar el sistema. Los requerimientos se validan, el sistema se verifica.
Por eso se dice que los casos de uso guían el proceso de desarrollo de software.
Centrado en la arquitectura
La palabra arquitectura va definiendo distintos planos dando las distintas miradas que esa construcción
necesita, habrá un plano con toda la estructura, con las instalaciones eléctricas, etc. De la misma forma
nosotros en sistemas informáticos vamos a tener que crear modelos que nos muestren distintas vistas
o miradas del sistema. En conjunto va a mostrar distintos aspectos estáticos y dinámicos que sean
significativos para que yo lo pueda construir al sistema.
Por un lado tengo los casos de uso que trabajan toda la cuestión funcional y por otro lado tengo con
la arquitectura de software las distintas vistas del sistema que me van a mostrar aspectos de la
plataforma, de los componentes, de los nodos para que luego puedan ser implementados, conexiones
de red, consideraciones de implementaciones, aspectos de los requerimientos no funcionales que
deban ser modelados etc.
De esta forma yo tengo los casos de uso en la parte funcional y la arquitectura con las distintas miradas
y vistas que de alguna forma me van a construir los distintos planos del software.
Casos de uso y arquitectura se complementan y evolucionan en paralelo
Cuando nosotros desarrollemos un sistema y ejecutemos un conjunto de actividades tendremos
distintos modelos, distintas acciones que realizamos con estos dos ejes, los casos de uso y la
arquitectura del sistema.
Entonces en este proceso unificado la arquitectura va a trabajar con lo que es la forma del sistema y
los casos de uso van a trabajar con lo que es la funcion del sistema pero los dos deben estar integrados
y relacionados, no son dos cosas independientes sino que esas funciones del sistema van a estar
soportadas y sostenidas en toda la arquitectura en todos los componentes y toda la forma que el
sistema debe tener para poder funcionar.
Ninguna es suficiente por si misma, ambas deben equilibrarse existiendo una interacción entre ellas.
Los casos de uso deben encajar en la arquitectura cuando se llevan a cabo no pueden ser
descripciones de una lógica general de ideales sino que deben ser reales y poderse implementar y por
otro lado la arquitectura debe permitir el desarrollo de todos los casos de uso que se pueden ejecutar
y se pueden implementar ya sean los actuales o los que vengan en futuro en alguna proyección de
como va a ir creciendo el sistema en su escalabilidad, deben evolucionar en paralelo.
Análisis de Sistema Resumen Nicolás Aguirre
Iterativo e incremental
Esta es la forma en que ese conjunto de actividades y como el sistema en su totalidad se va a ir
construyendo, se va a ir haciendo con una serie de pasos que va a ir creciendo progresivamente, de
allí que tenemos por un lado el concepto de iteración, que esta referido al conjunto de pasos que se
van a ejecutar y eso significa pasar por los distintos grupos de trabajo. Por cada iteración que yo voy
haciendo que es un ciclo voy logrando un incremento del sistema y de esa forma el producto va
creciendo hasta que en algún momento la última iteración me completa todas las funcionalidades del
sistema y es el ultimo incremento. Cada iteración debe estar planificada, controlada en su avance para
poder garantizar que los tiempos, los recursos, y los costos en los cuales vamos a incurrir estén
controlados.
Cada iteración comprende una serie de pasos que pasan por todos los flujos de trabajo, que incluyen
actividades de análisis de requisitos, de análisis propiamente dicho, de diseño, de implementación y
de prueba de sistema.
Con estas 3 características es como el proceso unificado establece sus características para poder
llevar acabo este conjunto de actividades y lograr el desarrollo de un sistema.
El ciclo de vida del proceso unificado

El ciclo de vida del proceso unificado va a presentar un esquema o un diagrama en donde tiene por
un lado cuatro grandes columnas que las llamamos las fases de este ciclo de vida, que se llaman
inicio, elaboración, construcción y transición. Luego tenemos los distintos flujos de trabajo, cada
iteración pasa por cada flujo del trabajo y cada interacción va haciendo una versión del sistema y esta
representando el incremento que recién vimos hasta llegar a una ultima iteración (n) que va a tener el
ultimo incremento y el sistema completo según lo acordado en el alcance, por el listado de
requerimiento funcionales y no funcionales, etc.
Entonces el proceso unificado se repite a lo largo de una serie de ciclos, cada una de estar iteraciones
y es lo que constituye el ciclo de vida de ese sistema.
De estas 4 fases, la de inicio estaría comprendiendo una serie de tareas que tienen que ver con la
definición del alcance del proyecto, la descripción del producto final, todo o que este trabajo de análisis
del negocio, la viabilidad del sistema y acá determinamos los requerimiento funcionales, las principales
funciones del sistema y los no funcionales, la arquitectura del sistema mas otros aspectos que tienen
que ver con la implementación y consideraciones para esa arquitectura. También se considera todo lo
que es el plan del proyecto, justamente el diagrama de Gantt, una serie de tareas con tiempo estimados
y un presupuesto que acompaña a toda esa definición.
Análisis de Sistema Resumen Nicolás Aguirre
Luego viene la fase de elaboración donde se va a especificar los casos de uso, con los diagramas,
descripción de casos de uso y diseño de los prototipos, además de eso también se va a hacer el diseño
de la arquitectura don distintas vistas arquitectónicas y el uso de todo lo que propone UML para la
creación de los distintos modelos. Hay otros diagramas que se crean acá como el de flujo de trabajo
de análisis y algunos diagramas del flujo de trabajo de diseño, estos diagramas de interacción van
formando parte de esta fase de elaboración.
Luego viene la fase de construcción que esta orientado a lo que es la codificación propiamente, la
programación del sistema o la creación del producto y las pruebas internas, la tarea de verificar el
sistema viendo que funcione de acuerdo a lo que tiene que cumplimentar.
Por ultimo viene la fase de transición en donde ya se empieza a instalar el producto en su versión beta,
terminando con el ultimo incremento con el sistema instalado y un tiempo de prueba por parte de esos
futuros usuarios donde ya van a ejecutar en su negocio, en su espacio de trabajo un tiempo de ajuste
para que el sistema se adapte y funcione correctamente según esas necesidades. Eso de instalar el
sistema, de hacer el mantenimiento y cierre es todo lo que se llama la integración y el despliegue,
cuando se lo instala en forma completa y ejecuta las funciones del mismo.

Cada una de las fases en relación a cada uno de los flujos de requisitos donde tiene mayor tiempo de
esfuerzo y de trabajo la actividad y como va disminuyendo conforme ese avance en las fases o
iteraciones. La parte de requisito tiene un fuerte trabajo desde el inicio durante la fase de la elaboración
y gran parte de la construcción y sobre el final esto de si vienen nuevos requerimientos será parte de
un nuevo convenio , un nuevo acuerdo, una nueva escalabilidad o crecimiento a futuro del proyecto
pero todo el trabajo de ingeniería de requerimientos se trabaja en estas primeras fases.
Luego los demás como análisis ,diseño ,implementación y prueba se van ejecutando en mayor o
menos proporción conforme se avance en las fases.
Fases y flujos de trabajo de un ciclo
Flujo de trabajo de requisitos: lo que busca es identificar los requisitos del sistema y construir un
modelo de requisitos a través de casos de uso. Cada flujo de trabajo tiene como su resultado la
creación de un modelo, el modelo con el nombre del flujo que estamos hablando, si el flujo es el de
trabajo de requisitos es el modelo de requisitos. Lo importante es que va a identificar requisitos y los
va a modelar a través de casos de uso, ese es su principal fin.
Análisis de Sistema Resumen Nicolás Aguirre
Flujo de trabajo de análisis: va a partir de esos requisitos y los va a estudiar y le va a dar una mirada
refinando y estructurándolos construyendo el modelo de análisis.
Flujo de trabajo de diseño: le va a dar la forma, es donde le agrega el cómo va esto a funcionar y
construye el modelo del diseño.
Flujo de trabajo de implementación: le agrega toda la parte de codificación al diseño y construye el
modelo de implementación. El resultado de cada flujo de trabajo es un modelo que lleva su nombre.
Flujo de trabajo de prueba: va a verificar que lo que esta programado es acorde a los requisitos a lo
que necesita el cliente, o sea si cumple con los requisitos y va a construir el modelo de pruebas.
Conceptos básicos del proceso
Flujo de trabajo (Workflow): el proceso unificado es el conjunto de actividades de todas las tareas que
hay que llevar a cabo para desarrollar un sistema con el uso de fundamentos, practicas, métodos y
demás. Cada flujo de trabajo va a definir el conjunto de actividades referidas a esa parte y va a definir
que rol de trabajador van a realizar que actividades y van a producir que resultados. Cada flujo de
trabajo define ese conjunto de actividades de todo lo que se debe desarrollar para poder construir el
sistema dentro del flujo de trabajo que hace referencia.
Trabajador: persona que van a ejecutar esas actividades y que al ejecutar esas actividades van a
producir un resultado que van a ser los artefactos y haciendo una serie de tareas o las actividades de
cada flujo de trabajo.
Actividades: tareas que se van a ejecutar. Unidad de trabajo tangible, ejecutada por un trabajador en
un flujo de trabajo. Son las distintas tareas para realizar en cada flujo de trabajo para realizar los
artefactos necesarios. Implica una responsabilidad bien definida para el trabajador que produce un
resultado bien definido.
Artefacto: es ese resultado que concretamente va a ser una especificación, un modelo, un diagrama,
algo concreto que es resultado que ese trabajador ejecute esa actividad dentro de un flujo de trabajo.
Toda esta metodología lo que busca es con
sus características de dirigidos por casos
de uso, ejecutando un ciclo en una serie de
iteraciones y un incremento va a ir
construyendo el sistema con el uso de la
creación de distintos modelos y diagramas
que propone UML partiendo de un flujo de
trabajo de requisitos en donde va a construir
un modelo de casos de uso que cuando
pase al siguiente flujo de trabajo de análisis
que va a construir un modelo de análisis,
esos casos de uso van a ir dirigiendo en un
hilo conductor que a medida que
avanzamos en todo el desarrollo de sistema
vamos avanzando en los distintos flujos de
trabajo haciendo algo con ese caso de uso.
El modelo de diseño va a hacer la realización de casos de uso, el modelo de despliegue esta dentro
de lo que es el flujo de trabajo de implementación con el modelo de implementación, van a estar
Análisis de Sistema Resumen Nicolás Aguirre
mostrando como es su arquitectura y como se implementa con sus distintos componentes y el modelo
de prueba va a estar ejecutando los distintos casos de prueba y lo va a ir verificando al sistema. De
esta forma el sistema se desarrolla de forma completa dirigida por casos de uso.
¿Qué es UML?

Estructura de UML

Bloques de construcción
Dentro de los elementos del bloque de
construcción están agrupados en cuatro
subgrupos, lo importante es que estos
bloques de construcción y estos
elementos son para poder construir alguno
de los diagramas y los distintos modelos.
Análisis de Sistema Resumen Nicolás Aguirre
Bloques de construcción de UML: Relaciones en UML 2.0
Son todas las relaciones posibles.

Bloques de construcción de UML: Diagramas

Estructura de UML
Dentro de esa estructura hay una serie de reglas que se aplican en los diagramas. Especifican a que
debe parecerse un modelo bien formado. Que sea semánticamente auto consistente y esté en armonía
con todos sus modelos relacionados.
UML tiene reglas semánticas para
Nombres: como llamar a los elementos, relaciones y diagramas.
Alcance: el contexto que da un significado especifico a un nombre,
Visibilidad: como se pueden ver y utilizar esos nombres por otros elementos, relaciones y diagramas.
Integridad: como se relacionan apropiada y consistentemente unos elementos con otros.
Ejecución: que significa ejecutar o simular un modelo dinámico.
Las reglas se complementan con una definición dentro de UML de lo que se llaman mecanismos
comunes que también complementan a esa regla con todos los patrones de características comunes,
de distintos estilo, de distintos detalles a considerar para el modelo.
Análisis de Sistema Resumen Nicolás Aguirre

Arquitectura del sistema

Comprende toda esta definición de la estructura propiamente y el comportamiento de un sistema,
adema del uso. Vamos a definir todos esos aspectos que hagan a implementación, consideración de
restricción económicas, tecnologías, aspectos estéticos. Mas bien todo aquello que va considerando
el dirigido por casos de uso y centrado en la arquitectura, que va a definir la forma de este sistema con
las distintas vistas.

Vistas de un sistema con UML

La arquitectura me va a crear estas distintas vistas, va a mostrar aspectos estáticos y dinámicos del
sistema construyendo distintas vistas. Me va a presentar una serie de estos diagramas agrupados en
distintas vistas y de esa forma me va a poder crear los distintos planos del software.
La arquitectura del sistema comprende 5 vistas:
Las vistas de los casos de uso esta central porque tiene
todo un hilo conductor dirigido por casos de uso y se
complementa con las otras 4 vistas. Cada vista es como
una mirada diferente con algún aspecto estático o
dinámico de lo que queremos mostrar del sistema.
Si construimos un diagrama de casos de uso estamos
mostrando un plano de sistema de las funciones de
sistema y va a formar parte de lo que es la vista de los
casos de uso y esa vista esta conformando la
arquitectura de una parte del sistema.
Análisis de Sistema Resumen Nicolás Aguirre

Flujo de trabajo de requisitos

Propósito
Este flujo tiene como principal objetivo o su propósito fundamental es detectar los requisitos y guiar el
desarrollo de todo hacia el sistema correcto. Guía el desarrollo correcto porque en este flujo vamos a
identificar esos requisitos y los casos de uso y como una de las características del proceso unificado
es guiado por casos de uso este flujo de requisito lo que va a tratar de definir es esos casos de uso y
guiar todo el sistema a su desarrollo completo. La idea es que en este flujo se logre una descripción
que sea completa, suficiente y que especifique todos esos requisitos, lo vamos a hacer con las
herramientas vistas en especificación de requerimientos. De alguna forma en esta descripción de lo
que va a hacer el sistema justamente va a definir el que debe hacer el sistema y no va a definir el como
y en este que debe hacer también va a dejar este alcance de que cosas van a estar contempladas y
cuales no , es decir, lo que no debe hacer el sistema.
Es una descripción completa que va a cubrir todos los requerimientos y los va a especificar.
Análisis de Sistema Resumen Nicolás Aguirre
Pasos del fujo de trabajo de requisitos
Dentro de este flujo para poder llevar a cabo todas las tareas hay una serie de pasos que tienen que
ver con:

Cuando nosotros hagamos esta tarea del proceso de ingeniería de requerimientos siempre que
encaremos un sistema debemos encontrar que necesita cubrir ese sistema, encontrar y describir que
necesita ese negocio y a partir de ahí construir un modelo que cubra esos requerimientos.

Actividades y trabajadores
Esto lo que va a tener como un ordenamiento de la metodología del proceso unificado de desarrollo
para ejecutar todas estas tareas que incluye este flujo de trabajo de requisitos.
Se reconocen cuatro roles para los trabajadores que van a participar en este flujo de trabajo. Esto
como es una metodología propone los roles que las distintas personas que participan en un desarrollo
de sistema tendrían que asumir, después en la realidad puede ser que una persona ejecute varios
roles dependiendo del proyecto y las personas que participan.
Analistas de sistemas: encuentran actores y casos de uso
Arquitecto: priorizan los casos de uso
Especificador de casos de uso: detalla los casos de uso
Diseñador de interfaz de usuario: hacen el prototipo de interfaz del usuario.
Análisis de Sistema Resumen Nicolás Aguirre

Artefactos y trabajadores
Además de trabajadores y actividades les vamos a agregar los artefactos, el resultado de ejecutar esa
actividad logra un producto, un artefacto.
El analista en sistema tiene como artefactos producidos el modelo de casos de uso, el actor y el
glosario. El especificador de casos de uso tiene como artefacto el caso de uso. El diseñador de interfaz
de usuario tiene como artefacto el prototipo de interfaz de usuario y el arquitecto produce la descripción
de la arquitectura.

Analista de sistema
Análisis de Sistema Resumen Nicolás Aguirre
Como actividad es encontrar actores y
casos de uso y como producto tiene el
modelo de casos de uso, actor y glosario.
La acción de esto es identificar los
actores del sistema y las funcionalidades
del mismo. Todo lo que nosotros vimos
para el modelo de casos de uso para
poder construir un diagrama se aplica
acá, vamos a ir encontrando actores y a
medida que los encontramos vamos
encontrando casos de uso. También se
considera todo lo visto en la parte de
construcción del diagrama de casos uso
y la aplicación de patrones.
El glosaría puede llegar a agregarse una documentación como una definición de términos comunes
que se utilizan desde el inicio del desarrollo de un sistema hasta el final que puede servir para
establecer un vocabulario común entre todo el equipo de sistemas que participa allí y a veces hasta
definiciones de lo que es el negocio para que lo entiendan los distintos participantes. Yo empiezo a
desarrollar un sistema, teniendo que hacer el proceso de ingeniería de requerimientos encontrándolos,
cuando el equipo va trabajando deberá seguir un metodología y si se sigue el proceso unificado voy a
tener que crear una serie de modelo y documentos basándome en una serie de actividades que
establece la metodología. Entonces de esta forma lo que estamos haciendo es repasar que actividades
ejecutan bajo que rol alguien, parte del equipo de sistema, y que artefacto debe producir. UN glosaría
siempre hace falta para unificar toda la terminología que vamos utilizando dentro de un sistema.
Puede llegar a ser necesario en el artefacto modelo de casos de uso cuando tenga el diagrama
completo esto de agrupar en paquetes para poder manejar o dominar el tamaño del mismo.
Arquitecto
Una vez que yo encontré actores y casos de uso con cuales empiezo a trabajar primero, cuales
empiezo a describir primero, cuales serian parte de mi primera iteración. Voy a tomar la lista completa
de los requerimientos, suponiendo tenemos 120 casos de uso y la idea es con cual empiezo, si el
sistema fuere de comercializar puedo empezar por registrar un cliente, un producto, un pedido, generar
un reporte, anular una factura, yo le voy a dar un orden por cuales voy a empezar. La secuencia lógica
siempre empieza con las transacciones e información que empiezan desde un inicio de todo un circuito
y uno va priorizando y avanzando en las distintas funciones quedando para el ultimo los reportes y en
el medio van quedando las transacciones subsiguientes, empezamos con los casos de uso que
atiendan la primera información y luego conforme avanza el ciclo de proceso de ese proceso de
negocio ir atendiendo las prioridades 2,3,4 en ese orden hasta llegar a los reportes que quedan al final
porque los vamos a poder generar una vez que tengamos las transacciones, el registrado de los datos
y la estructura
El artefacto que produce es la descripción de la arquitectura donde voy a tener una vista del modelo
de casos de uso con los casos de uso significativos, en respuesta o como resultado de esa priorización
en que orden vamos a irlos trabajando. Debería incluir los casos de uso que describan alguna
funcionalidad importante, y critica, o que impliquen algún requisito importante que deba desarrollarse
pronto, dentro del ciclo de vida de software.
Análisis de Sistema Resumen Nicolás Aguirre
Especificador de casos de uso
Tiene la actividad de detallar un caso de uso y como artefacto el caso de uso. Concretamente es la
descripción de toda la secuencia lógica que ejecuta un caso de uso, entonces al artefacto lo llama
caso de uso, pero no es que acá lo identifica ya que lo hizo en la primer actividad del analista, acá es
la descripción propiamente en algún formato particular como la plantilla. Se aplican todas las
consideraciones que los patrones de casos de uso indican.
Acompañando esto de la descripción del caos de uso tenemos un diseñador de interfaz de usuario
que se encarga como actividad de prototipar la interfaz de usuario y el resultado del mismo es el
prototipo de interfaz. Comprende el diseño de la o las ventanas que va a tener el sistema.
Analista de sistema (otra vez)
Es la parte de estructurar el modelo de casos de uso, retornando como artefacto el modelo de casos
de uso. Esto significa que cuando vamos construyendo el diagrama, encontramos actores, casos de
uso, vamos describiendo y estructurar el modelo es completar ese diagrama con todas las relaciones
posibles entre casos de uso denominadas como inclusión, extensión y generalización, también se
incluye todo lo que proponen los patrones. Esta actividad se va a ver reflejada en el mismo modelo de
casos de uso en un diagrama donde le voy agregando las relaciones de inclusión, extensión y demás.
El diagrama de las actividades (página 198) muestra como una forma de secuencia, pero no es
exactamente secuencial, sino que es el conjunto de actividades necesarias que pueden estar
desarrolladas de forma paralela para poder construir todo el modelo de requisitos o requerimientos
resultado de este flujo de trabajo.
Flujo de trabajo de análisis
Propósitos
Tiene 3, su foco principal es estudiar los requisitos tratando de darle una mirada interna, tratando de
profundizar sobre esos requisitos que quedaron enunciados y descriptos en el caso de uso y vamos a
darle otra mirada buscando la intención de refinarlos y estructurarlos. Es una forma de darle una vista
interna, la descripción de casos de uso tiene una mirad externa, yo ahora me voy a meter dentro de
ese caso de uso y voy a ver por detrás que clases van a estar sustentando toda esa ejecución del caso
de uso, que estructuran van a tener, como los agrupo en paquetes y que objetos van a colaborar
perteneciendo a esas clases para ver como se ejecuta y lleva a cabo esta solución. De allí a que es
una mirada.
Por ejemplo, en el caso de uso voy a ir diciendo en la serie de pasos, contando la lógica, ese paso
como esta descripto en el flujo de trabajo de análisis voy a buscar un diagrama y les voy a dar una
mirada interna viendo si exactamente ese paso como puedo concretarlo, modelando con distintos
diagramas, encontrando clases y viendo como los objetos colaboran entre si para poder ejecutar esa
función. De alguna forma, con este flujo de trabajo de análisis voy a conseguir una comprensión mas
precisa de los requisitos y una descripción, utilizando todo lo que es el paradigma orientado a objetos,
y voy a darle una estructura a todas esas clases con un diagrama en donde yo muestre esa ejecución
y que actividad tiene en cuenta el sistema y la idea es crearlo de una forma tal con toda esta
fundamentación de la orientación a objetos para que después puedan ser mantenibles en el tiempo,
se pueda hacer reutilizo de los mismos y aplique todos estos elementos que me propone el paradigma.
Como tercer propósito es razonar y definir una serie de aspectos que tienen que ver con una vista
interna del sistema. Esto que yo voy definiendo esta muy orientado a que le sirva dentro del equipo de
Análisis de Sistema Resumen Nicolás Aguirre
sistema a los programadores ara poder implementar esto con un lenguaje orientado a objetos en
función de todo este modelo conceptual que estoy haciendo y este modelo de análisis que estoy
planteando en este flujo de trabajo.
Comparación entre F.T de requisitos y análisis

Actividades y trabajadores
Análisis de Sistema Resumen Nicolás Aguirre
Artefactos y trabajadores

Actividades
Análisis de la arquitectura
El arquitecto tiene como actividad el análisis de la arquitectura, por un lado, vamos a identificar
paquetes de análisis, que son agrupaciones según algún criterio. Si yo estoy agrupando clases, serán
paquetes de clases de análisis, si agrupo casos de uso serán paquetes de casos de uso. Cuando
vimos casos de uso, si uno tiene un diagrama de casos de uso con muchos casos de uso puedo
agruparlos a esos casos de uso con funciones relacionadas y armar paquetes para hacer mas
manejable un modelo de casos de uso. La diferencia ahora es que como ahora voy a identificar clases,
cuando yo voy construyendo un diagrama completo de clases y voy a construir los diagrama dentro de
este modelo de análisis va a llegar un momento donde se transforma medio inmanejable por la
cantidad de clases que tengo, entonces las voy a agrupar en paquetes y como estoy trabajando con
clases de análisis son paquetes de análisis.
Aparte de identificar esos paquetes, también voy a identificar clases de identidad obvias que es un tipo
de clases que ya se verá más adelante.
Por otro lado, dentro de esta misma actividad, una tercer tarea es identificar requisitos especiales
comunes como seguridad, persistencia, concurrencia, tolerancia a fallo, distribución, etc. Esto significa
que ese listado de requerimientos no funciónales que detectamos en el flujo de trabajo de requisitos,
cuando voy al análisis voy a tener que analizar si estos requisitos en la forma que tiene el sistema y
en como se puede implementar que debo ir considerando, que debo ir agregando y que puede llegar
a cambiar. Entonces esa sería mi primer actividad, el análisis de la arquitectura.
El resultado de esa actividad va a permitirme construir dos artefactos: por un lado, el modelo de análisis
y por otro lado la descripción de la arquitectura. El modelo de análisis va a ser un modelo que va a
estar mostrando una serie de diagramas y esos diagramas van a estar agrupados en paquetes por la
dimensión que va a tomar el sistema. Los casos de uso se van a describir mediante clases de análisis
y sus objetos y como los objetos colaboran entre sí.
Por otro lado, vamos a tener la descripción de la arquitectura en donde esa descripción de la
arquitectura va a tener una vista que va a mostrar los artefactos mas significativos para la arquitectura.
Análisis de Sistema Resumen Nicolás Aguirre
Actividad de analizar un caso de uso
Es la actividad del ingeniero de casos de uso. Consiste en identificar clases de análisis participantes.
Es acá donde vamos a considerar los distinto tipos de clases de análisis, y vamos a describir la
interacción entre objetos de análisis.
El resultado de hacer esta actividad me da un artefacto que se llama la realización de caso de uso-
Análisis. Una realización de caso de usos-análisis es una colaboración que va a describir como se
lleva a cabo y se ejecuta un caso de uso. Nosotros tenemos un caso de uso con una descripción y
tienen los pasos que formulan, por ejemplo: “El sistema muestra los datos del cliente” eso es un paso
que estaría siendo de una mirada externa cuando creamos el modelo de casos de uso y la descripción.
La realización de caso de uso-análisis va a tomar el caso de uso, se va a meter con una mirada interna
y va a ver como hace el sistema para poder mostrar esos datos del cliente y va a ver que objetos
intervienen y como colaboran entre si, si un objeto tiene la información, si necesita colaborar con otro
y va a construir información para poder visualizar ese dato, hacer un calculo o hacer cualquier acción.
Esta colaboración que nosotros queremos mostrar nos valdremos de un diagrama para poder
representar este análisis que estamos haciendo y modelar y mostrar como seria la colaboración
surgiendo los diagramas de interacción, concretamente los diagramas de comunicación y de
secuencia.
Eso sería una realización de caso de uso-Análisis dar una mirada interna a como se ejecuta el caso
de uso y ver como los objetos colaboran entre si y utilizar un diagrama para representar esa
interacción.
Actividad analizar una clase
El ingeniero de componentes tiene como actividad analizar una clase, lo cual significa que yo por cada
clase identificada y con esa mirada interna que quiero hacer, para ver los objetos que van a colaborar
entre si tengo que identificar ese conjunto de objetos que clases conforman. Entonces voy a ir
identificando clases, atributos, responsabilidades, vamos a identificar asociaciones de agregación y
composición, generalización . Cuando yo voy haciendo el análisis de una clase voy a agregar además
encontrar otro tipo de clases y vamos a agregar otro tipo de relación, las dependencias. El resultado
de esta actividad va a ser un diagrama que se llama diagrama de clases de análisis que retoma o parte
del diagrama de clases y le va a agregar todas las consideraciones de análisis, una vista interna, otro
tipo de clase y además otro tipo de relación posibles (las dependencias) y va a construir el diagrama
de clases de análisis. Va creciendo ese diagrama y como va creciendo va a tomar una dimensión
bastante amplia, surgiendo la necesidad de encontrar paquetes.
El resultado de realizar esta actividad es el artefacto llamado Clases de Análisis que concretamente
es encontrar la clases y definirla en sus partes de atributos, responsabilidades y relaciones entre todos
pero en este caso vamos a incluir las clases que nosotros conocemos que son las de entidad y otras
que ya se verán.
Tipos de clases
Esos son los
tipos de clases,
esos tres tipos.
Análisis de Sistema Resumen Nicolás Aguirre
Una clase entidad es lo que veníamos modelando en un diagrama de clases son de entidad. Significa
que son persistentes, contienen información que a futuro va a estar contenido en una base de datos y
va a guardar información.
Las clases de interfaz va a ser aquello que va a estar representando algo y va a servir como mediación
entre el ambiente (alguien de afuera que ingrese datos, que capture datos) y el sistema. Por otro lado,
todo lo que el sistema necesite mostrar va a estar esta clase de interfaz que va a permitir brindarle
información al entorno, a los actores.
Las clases de control va a manejar o administrar el comportamiento especifico de un caso de uso.
Actividad de analizar un paquete
El paquete es la agrupación de algo de un conjunto de elementos dentro de algunas características,
en este caso son paquetes de análisis para poder controlar la complejidad o la dimensión del sistema
que estamos modelando. La idea es que cuando vamos agrupando en paquetes la búsqueda en esa
agrupación es tratar de que haya un bajo acoplamiento y una alta cohesión lo que quiere decir que la
agrupación este bien hecha para lograr la mayor independencia entre los paquetes, eso es el
acoplamiento mínimo, y las clases que están agrupadas y lo que está conteniendo cada paquete tenga
una alta cohesión, corresponda a esa agrupación. Eso es lo que buscamos en la actividad de analizar
un paquete.
Como resultado de esta actividad es el artefacto que se llama paquete de análisis, el paquete entonces
va a estar agrupando bajo algún criterio de agrupación un conjunto de clases. Es un mecanismo lógico
de agrupación que proporciona un espacio del nombre para sus miembros, vamos a agrupar paquetes,
les vamos a dar un nombre y ese paquete va a agrupando clases de análisis, realizaciones de casos
de uso y a la vez podría tener otros paquetes de análisis, podría tener una estructura jerárquica en
donde haya paquetes que contienen paquetes, otros elementos y voy descendiendo por nivel hasta
lograr una construcción de todos esos paquetes y de todos los elementos dentro de este flujo de trabajo
de análisis.
Análisis de Sistema Resumen Nicolás Aguirre
Resumen de analizar un caso de uso

Diagrama de comunicación
Va a representar la organización de los objetos que participan entre si para poder ejecutar una acción
y la idea es que el diagrama muestre como esos objetos, uno hace una petición a otro, como colaboran
entre si y logran modelar y llevar a cabo el comportamiento de un caso de uso en particular o una parte
de un caso de uso porque a veces en los diagramas pueden haber vistas parciales.
Yo tengo un caso de uso como una descripción de pasos, esa fue la vista externa en el modelo de
requisitos. Cuando quiero hacer esa mirada interna voy a tomar paso por paso de esa descripción y
voy a ver cuales son las clases de análisis que por detrás están sosteniendo esa ejecución del caso
de uso y los objetos de esas clases y los objetos de un tipo de clases de análisis como colaboran entre
si. Es como que en este diagrama de comunicación vamos a tener muchos conceptos del paradigma
orientado a objetos y mucho de los fundamentos vistos, viendo concretamente como los objetos
colaboran entre si para ejecutar esa función. Si yo digo que un caso de uso es registrar un nuevo
cliente y realice una descripción de los pasos para poder registrar un nuevo cliente y diseñe un
prototipo, lo valide con el cliente y estamos viendo que ese prototipo tiene una serie de datos y va a
estar en concordancia con la descripción de casos de uso, ahora para todos esos pasos descriptos en
un lenguaje del cliente le voy a dar esa vista interna, encontrando clases de análisis, paquetes de
análisis y voy a describir con un diagrama algo que le sirva al desarrollador para que pueda programar
esa funcionalidad.
Muestra también una información estructural, en el sentido de las relaciones entre objetos y esos
objetos deben colaborar entre ellos para lograr cumplir con el comportamiento deseado del sistema.
Por otro lado, también son la principal fuente de información para determinar las responsabilidades de
las clases intervinientes y es u diagrama de interacción de UML 2.0
Elementos del diagrama de comunicación
Los tres elementos para poder construir un diagrama de
comunicación son estos:
Análisis de Sistema Resumen Nicolás Aguirre
Objetos
Nosotros vamos a tener que identificar objetos. Todo objeto pertenece una clase ya que el conjunto
de objetos con estructura y comportamiento común es lo que conforma una clase. Aparte de identificar
objetos que correspondan a una clase vamos a considerar los tipos de clases que vimos, que son las
clases de interfaz, clase de control y clase de entidad.
Cuando voy analizando un caso de uso tendré que ver los objetos que participan allí, por cada uno
deberé tener en cuenta su tipo porque es una instancia de alguna clase.
Como la misma palabra lo dice, la interfaz si
va a estar relacionada con los prototipos.
Significa la cara del sistema, ese prototipo en
lo que es toda la simbología y fundamentación
de objetos va a estar representado por un
objeto de una clase de interfaz concretamente
porque es la cara del sistema que me permite
la conexión y la comunicación con el actor de
un sistema
Por cada actor que hemos identificado y por cada prototipo de interfaz que hemos diseñado significa
que allí aparece un objeto de interfaz, voy a tener una clase de interfaz con sus objetos. Esos objetos
se encuentran en el límite, relacionados con los actores. Cuando hicimos el diagrama de casos de uso
todos los actores van pro fuera, los casos de uso por dentro y hay una línea, justamente los objetos
de interfaz van a aparecer en esa conexión del límite porque permite la comunicación entre el sistema
y su entorno. El sistema los casos de uso y su entorno los actores.
Si nosotros tenemos el caso de uso registrar cliente y ese registrar cliente usa una o varias pantallas,
utiliza distintas interfaces, van a ser las distintas clases de interfaz en ese caso de uso que vamos
identificando. Todo lo que los sistemas actualmente hacen en comunicación con su entorno, con todos
los futuros usuarios, con todos los actores van a estar identificados y representados por una clase de
interfaz.
El objeto de control es aquel que coordina toda
la ejecución del caso de uso y va a tener una
serie de responsabilidades asociadas para que
se pueda ejecutar realmente el caso de uso.
En general todo caso de uso vamos a
modelarlo en uno o varios diagramas de
comunicación. Cuando tengamos un diagrama
de comunicación en general tenemos un objeto
de control de esa clase. Hay casos especiales
en donde si el caso de uso es muy complejo
podemos tener mas de un objeto de control
para ese diagrama de comunicación y si el caso
de uso es demasiado simple podríamos no
tener un objeto de control porque no me hace falta una coordinación ya que es sencillo y la interfaz se
comunica con la entidad. En general es como se utiliza el objeto control y siempre aparece en un
diagrama de comunicación.
Análisis de Sistema Resumen Nicolás Aguirre

Cuando yo voy a representar un diagrama de comunicación voy a modelar objetos de este tipo.
Simbología y notación
Normalmente va a ser ese objeto que encontramos representado con un símbolo de objetos que
depende del tipo de clase y eso va a llevar un nombre y ese nombre va a estar subrayado. Además
de modelar objetos, que son instancias de clases, yo también voy a modelar a los actores con esta
representación con el nombre del actor o instancias de actores que van a aparecer porque los
identificamos en el modelo de casos de uso y están descriptos en el caso de uso. Vamos a usar en un
diagrama de comunicación el icono que representa un actor y el mismo nombre que le han dado que
esta representado en el diagrama de casos de uso también lo vamos a poner acá como una instancia
de actor y va a ser un objeto para el diagrama de comunicación.
Análisis de Sistema Resumen Nicolás Aguirre

Que consideración puede llegar a tener el objeto de entidad: antes de los dos puntos habrá ocasiones
que le pueden dar algo mas que agreguen algo delante de los dos puntos. Cuando en un diagrama de
comunicación vamos a modelar un objeto que representa una única instancia de una case delante de
los dos puntos le ponemos un nombre.
Enlaces
Si yo tengo un objeto A identificado y un objeto B y necesito que interactúen A con B tendré que
establecer un enlace para que se envié un mensaje. La idea es que yo vaya descubriendo que objetos
necesitan conectarse e interactuar entre ellos. El enlace es una relación entre objeto a través de la cal
se pueden enviar mensajes y se va a representar con una línea que haga la conexión entre esos
objetos o instancias de clases. El establecer esto va a permitir luego que se puedan enviar mensaje o
navegar entre esos objetos.

Para construir un diagrama de comunicación partimos de la descripción que tenemos que tener a mano
mas el modelo de objetos del dominio porque ese modelo ya tiene clases de entidad, y la descripción
me está contando la lógica, la descripción con los pasos más el prototipo.
Estamos en el caso de uso de registrar pedido, el primero paso del caso de uso empieza diciendo esta
formalidad: “El actor inicia o ingresa …” Esto esta sostenido en la descripción, un prototipo, un
diagrama de casos de uso y tenemos nuestro modelo de objetos del dominio.
Si yo tengo que empezar a graficar algo comenzaría con el actor. Si yo tengo que el paso 1 del caso
de uso indica un actor, significa que el diagrama de comunicación va a tener un actor, dibujo el icono,
le doy el nombre, la notación, van con dos puntos, va el nombre y subrayados. Después viene un
enlace ya que dice que ingresa la opción de registrar un pedido, eso significa que en el menú de
opciones selecciono la opción y aparece la pantalla de registros de pedidos, esa pantalla principal va
a ser un objeto de interfaz de una clase de interfaz. Establezco un enlace, utilizo el icono que
Análisis de Sistema Resumen Nicolás Aguirre
representa una clase de interfaz y le doy un nombre que tenga que ver con el caso de uso que estoy
modelando. Establecemos un enlace, representamos el icono y muestra la pantalla, eso es porque la
clase de interfaz es mediadora entre el entorno y el sistema. Yo para que el sistema haga algo mostré
una cara que es el prototipo de interfaz, en un diagrama este se representa con un objeto del tipo de
clase de interfaz, luego la notación con dos puntos , el nombre mas el subrayado. Luego que entro a
esa pantalla el sistema inicia y vamos a ejecutar algo teniendo que aparecer un objeto de control para
que empiece a organizar la coordinación de envío de mensajes y demás, entonces establezco un
enlace , represento con un icono un objeto de control y le doy con el nombre la notación
correspondiente. Los objetos de control que pertenecen a una clase de control tienen la terminología
de manejador de , controlador de, gestor de registros de pedidos, son términos validos para darle
nombre a un objeto de control. Para esta opción estos son los primeros elementos, así se empieza a
construir el diagrama de comunicación, a partir del caso de uso con su descripción y a partir de lo que
voy identificando que esta enunciado le doy una mirada interna, empiezo a trabajar con clases de
análisis, utilizo elementos del diagrama de comunicación y empiezo a representar.
Esta mirada interna significa estructurar y refinar los requisitos, ese primer propósitos que teníamos
que el modelo de análisis estructura y refina los requisitos que fueron identificados en la captura de
requisitos significa hacer este trabajo: una mirada interna, ver que objetos colaboran entre si, que
mensajes se envían, y de esta forma como ejecuta el caso de uso y obtiene el resultado que es el
objetivo del caso de uso. A su vez esto es dirigido por casos de uso, se identifican en el modelo de
requisitos y cada modelo siguiente toma el caso de uso y le agrega una mirada, obtiene una vista,
construye un diagrama, pero siempre por el caso de uso identificado va pasando por todos los flujos
de trabajo.
Por ultimo aparecen los objetos de entidad según el modelo de objetos de dominio según la descripción
del caso de uso.
Mensajes
Un mensaje va a ser esa comunicación entre objetos, si yo establecí que un objeto A tiene un enlace
al objeto B el mensaje va a ser esa petición. Todo el paradigma orientado a objetos propone una forma
en que los objetos colaboren entre si y ejecuten una acción. La forma de colaboración es entre
peticiones, un objeto tiene un conjunto de atributos y una serie de responsabilidades y va a ver si
necesita colaborar, pedirle ayuda a otro objeto para poder ejecutar una función y de esa forma
empiezan a aparecer los mensajes, necesito que el objeto X haga tal cosa, voy obteniendo una
respuesta a esos mensajes, un resultado y ejecuto todos los pasos descripto en el caso de uso.
Un mensaje es una comunicación entre objetos que transporta información con la finalidad que se lleve
a cabo una actividad, hago una petición y obtengo una respuesta en función de lo que la petición este
buscando. La forma que va a tener es que todo mensaje va a tener una numeración y va a tener el
nombre o el texto del mensaje y termina con los paréntesis. Este mensaje tiene la formad e método y
responsabilidad de una clase porque tiene correspondencia con este concepto. Se va a representar a
parte de tener numero y nombre del mensaje con una flecha y un sentido para mostrar el objeto emisor
y receptor, es decir, aquel a que se le hace la petición así el enlace se utiliza para transportar el
mensaje.
Análisis de Sistema Resumen Nicolás Aguirre

Un objeto A, en este caso un objeto de control, un enlace, un objeto B que es de entidad, y un mensaje
que va a llevar esta flecha que es una flecha con punta llena y tenemos el numero (2) y el nombre del
mensaje con un paréntesis. Que los mensajes se modelen sin parámetros ni valores de retorno
significa que estas formas que estamos viendo por ahora es un mensaje que a futuro va a ser un
método que se va a programar, todo mensaje puede tener dentro de los paréntesis una serie de valores
que son los parámetros y a la vez en función de la petición puedo obtener una respuesta que son los
valores de retorno, pero cuando estoy haciendo un diagrama de comunicación no modelo esos
elementos, ni parámetros ni valores de retorno. Lo que pasa es que a nivel de la lógica y construir un
diagrama de comunicación uno a veces lo va pensando que es necesario como parámetro como valor
de retorno porque se va aproximando a lo que va a ser luego la programación.
En el diagrama de comunicación buscamos establecer el mensaje, la petición que un objeto A le hace
a un objeto B y vamos a tener una suma de mensajes y de esa forma un conjunto de interacciones
entre objetos.
Cuando llegamos a hacer un diagrama de comunicación necesitamos, de todo el modelo de casos de
uso, la descripción porque nos va a ir dando el paso a paso para hacer esa vista interna, el prototipo
de interfaz para la lectura completa de la especificación, descripción , con su prototipo y necesitamos
el modelo de objetos del dominio donde están todas las clases de entidad de ese tipo definidas.
Algunas consideraciones mas del diagrama de comunicación
Nosotros podemos al menos hacer por cada caso de uso concreto un diagrama de comunicación, pero
no es la única construcción tan directa. Si los casos de uso son complejos yo podría hacer por el curso
normal lo que se llama un escenario y modelar un diagrama de comunicación para el escenario del
curso normal y podría hacer un camino alternativo que también tiene su complejidad otro diagrama de
comunicación para el escenario con un curso normal significativo que me lo represente medianamente.
Otra forma es que en el mismo diagrama podríamos poner el curso normal y luego en los últimos
mensajes que hacen alternativas que pueden ser mensajes de error o algo mas porque es sencillo y
lo podríamos tener en un solo diagrama de comunicación.
La otra es que el curso normal si o si separado en un escenario en un diagrama de comunicación y
todas las alternativas juntas que son pequeñas en otro diagrama de comunicación que vayamos
modelando.
Usaremos en función de la complejidad del caso de uso y cantidad de alternativas que tengamos para
saber si justifica integrado o separado.
Análisis de Sistema Resumen Nicolás Aguirre
Consideraciones generales
Una instancia de actor solo se puede relacionar con objetos de interfaz, porque es la mediadora entre
el entorno y el sistema, entonces siempre que haya un diagrama de comunicación la instancia de actor
solamente tiene enlace y mensajes con el objeto de interfaz.
En general los mensajes van dirigidos hacia el objeto de interfaz, esto sígnica que el actor ingresa la
opción, va a estar abriendo una pantalla y lo que la pantalla muestre o visualice no se ponen mensajes
de retorno o de vuelta, sino que el usuario los va a visualizar en pantalla, los mensajes en general son
de ida hacia el objeto de interfaz.
Vamos a tener alguna situación donde podría suceder que tengamos un actor que sea un dispositivo
hardware y que tal vez ahí si el sistema o el objeto interfaz le devuelva un mensaje o le envié un
mensaje a la instancia de actor, podría llegar a ser o si es un sistema donde necesitamos mandarle
algo.
Y por otro lado un objeto de entidad no envía mensajes al objeto de control. Los mensaje van hacia el
objeto de entidad, cada mensaje tiene parámetros y valores de retorno y este mensajes es una petición
del objeto A al objeto B, lo que este objeto B le devuelva va a ser parte de esa forma del método que
es el valor de retorno, no es una nueva petición que va del objeto de entidad hacia el objeto de control,
por eso no debemos modelar mensajes del objeto de entidad hacia el objeto de control, los mensajes
van en sentido contrario.
Se utilizara un * que es un mensaje que va a ser enviado a un conjunto o subconjunto, al menos a mas
de un objeto de esa clase.

Siempre que nosotros digamos un paso en la descripción :”El sistema hace tal cosa” significa cuando
vayamos al diagrama de comunicación que el manejador tendrá que hacer algo ante esa descripción
porque justamente el objeto a construir es quien coordina la ejecución del caso de uso y es quien
necesita pedir colaboración a otros objetos, responderle a la interfaz y actuar para que se pueda
ejecutar. Siempre que haya un paso que diga: “El sistema llama al caso de uso xx” habrá un mensaje
self que es un mensaje a si mismo en el objeto control para coordinar esa acción, la numeración según
la secuencia de acción que vengaos enumerando donde tendremos que poner ejecutar caso de uso
xx. Eso seria cuando hacemos el diagrama de comunicación del caso de uso base porque la
descripción en ese momento dice que se llama a otro caso de uso. Cuando esto después se programa,
internamente habrá una llamada a una subrutina.
Análisis de Sistema Resumen Nicolás Aguirre

Cuando en una descripción de un caso de uso se generan salidas impresas como emitir un
comprobante, una factura, etc. Esas son salidas, en ese caso nos vamos a valer de un tipo de clase
que son las clases de interfaz que permiten modelar objetos que sean pantallas, salidas de distinto
tipo, impresiones o formato de archivo, todo lo que sea el resultado de algún proceso que genere una
salida en alguna función del sistema estará modelada por objetos de interfaz que son del tipo de clase
de interfaz. Llevara el mismo formato con dos puntos nombre y subrayado pudiendo llevar el nombre
“impresor” o “archivo”, etc.
Tenemos dentro de un comprobante de
pago que se emite, habrá un mensaje
en el manejador o en el objeto de
control que diga: “imprimir
comprobante” y tendrá otro objeto de
interfaz y el mensaje es imprimir, en
este caso impresión de un
comprobante.

Cuando nosotros tengamos en un diagrama de casos de uso una construcción de casos de uso de
generalización con un caso de uso padre y dos o mas casos de uso hijo es importante saber que los
diagramas de comunicación se los construyen para los casos de uso hijos que se los llama concretos,
un caso de uso padre en una generalización si es abstracto, de ese no se va a hacer un diagrama de
comunicación, se hace solamente de los casos de uso hijo que son concretos que tienen la
funcionalidad integrada de lo que heredan mas lo propio, entonces solo modelamos un diagrama de
comunicación para casos de uso hijos concretos.
Análisis de Sistema Resumen Nicolás Aguirre
Patrones de comunicación: Patrones GRASP
GRASP: Patrones para la asignación de responsabilidades.
El concepto de patrones es el mismo, son soluciones ya probadas ante una problemática recurrentes,
pero vamos a encontrar patrones en distintas partes del desarrollo de un sistema. Estos patrones
GRASP atienden esa misma solución cuando uno va a construir un diagrama de comunicación a donde
asignar las responsabilidades, es decir, un objeto A a quien le puede mandar mensajes y que otro
objeto B es responsable de resolver esa petición.
Estos patrones se van a usar en la construcción de un diagrama de comunicación.
Los patrones son soluciones expresada en términos de objetos e interfaces se expresan en base a la
estructura y/o comunicación de objetos y clases para resolver los problemas del contexto.
Estos patrones también nos van a servir para todos los diagramas de interacción que son dos:
diagramas de secuencia y de interacción.
La importancia de estos patrones es que mientras nosotros asignemos correctamente la
responsabilidad al objeto, cuando esto pase la etapa de diseño de implementación o de programación
la codificación se va a realizar con la calidad correspondiente y el objeto que vamos a estar codificando
va a estar con la responsabilidad que le corresponde. Si no esta bien asignada la responsabilidad
tendremos errores en la programación porque vamos a tener una serie de mayor acoplamiento, menor
cohesión, el reutilizamiento no va a estar tan optimo si no construimos algo correcto. Se aplican durante
la construcciones de diagramas de interacción, al asignar responsabilidades a los objetos y al diseñar
la colaboración entre ellos.
La definición de responsabilidad en este contexto es el contrato u obligación de un tipo o clase. Las
responsabilidades se relacionan con las obligaciones de un objeto respecto a su comportamiento. Van
a ser los mensajes que nosotros representamos en un diagrama de comunicación que un objeto recibe,
si un objeto recibe un mensaje es su responsabilidad resolver esa petición y es también su
responsabilidad saber que, si tienen la información o los elementos, o los atributos o lo que le
corresponda a ese tipo de objeto poderlo resolver o delegar en otro objeto que lo ayude para resolver
esa petición.
Las responsabilidades que uno tiene que saber asignar corresponden a dos grandes categorías, a lo
que se llama conocer y al otro grupo que se llama el hacer.
Las responsabilidades relacionadas con el hacer se refieren en hacer algo en uno mismo significa que
el objeto recibe mensajes y tiene que saber si ese mensaje puede ser hacer algo con ese mismo
objeto. Por ejemplo, el objeto de control recibe un mensaje y tiene que saber que si necesita ayuda
para resolver eso. Iniciar una acción en otros objetos, justamente o lo puedo hacer yo o lo tengo que
delegar en alguien y por otro lado otra responsabilidad de hacer es controlar y coordinar actividades
en otros objetos , dependiendo de que objetos hablemos tendré que saber si lo puedo resolver o no.
Por ejemplo, el objeto de interfaz recibe por teclado un botón que le dice mostrar localidades, el objeto
de interfaz va a ver si tiene la información o puede hacer esa muestra de localidades en un combo, ve
que no, le pide al objeto de control que lo ayude ahí está iniciando una acción en otros objetos. Cuando
el objeto control recibe esa petición observa si tiene la información de las localidades o necesita pedirle
al objeto de localidad que le muestre y arme el combo y de esa forma trabaja en esta forma de asignar
responsabilidades
Análisis de Sistema Resumen Nicolás Aguirre
Las responsabilidades relacionadas con el conocer tiene que ver con estar enterado de los datos
privados encapsulados, acá se aplica el paradigma orientado a objetos cuyo elemento esencial es el
encapsulamiento, un objeto de entidad los atributos que tiene los tiene encapsulados, otro objeto no
conoce cual es el valor de ellos, entonces hay una dinámica entre objetos que hay que representar.
Entonces las responsabilidades relacionadas con el conocer tiene que ver con estar enterado de los
datos privados encapsulados, la existencia de objetos conexos , y de las cosas que se pueden derivar
o calcular.
Hay una lista larga de patrones, solo se mencionara 7 que son los que mayor aplicación van a tener:
Patrón experto, Patrón alta cohesión, Patrón bajo acoplamiento, Patrón Singleton, Patrón creador,
Patrón controlador, Patrón no hables con extraños, entre otros.
Diagrama de clases de análisis
Recordando lo siguiente:
En esa actividad de analizar una clase tiene que identificar los
distinto tipos de clases de análisis y como resultado como artefacto
final es un diagrama que se llama diagrama de clases de análisis.
Es el diagrama de clases que se le agrega las otras clases que vimos
de interfaz y de control que son las clases de análisis.

El diagrama de clases de análisis representa todas las clases participantes en la solución de análisis
que seria con todo este agregado de los tipos de clases nuevos. Un diagrama de clases es un modelo
que representa la vista de diseño estática y muestra un conjunto de clases y sus relaciones, para ello
considera los tres tipos de clases.
Elementos del diagrama de clases de análisis
Un diagrama de clases tiene clases y
relaciones vamos a tener los siguientes
elementos.
La dependencia se define como una relación
de uso, se va a aplicar una dependencia
cuando yo quiero modelar que una clase A
utiliza a la otra clase B, tiene un elemento
que utiliza a otro. La simbología es una
flecha con línea discontinua y flecha abierta.
La dependencia dura lo que dura la ejecución de esa función, de ese proceso, de ese elemento y luego
deja de existir.
Análisis de Sistema Resumen Nicolás Aguirre
Clase de entidad
Tiene como toda clase atributos y responsabilidad. Se consideran los
atributos del modelo de objetos del dominio, esos atributos ya existen
y permanecen, pudiendo agregarse algunos atributos porque después
del diagrama de comunicación encontramos un atributo nuevo que va
a ser persistente y se ubica en la clase de entidad correspondiente.
Cuando nosotros vamos modelando la gestión de usuario hay clases
o atributos que aparecen sumándose a lo anterior, porque hay que completar mas datos que cuando
pensamos el modelo lógico no apareció. Partimos desde lo que ya está definido y podrían surgir algún
nuevo atributo o alguna clase que contenga esos atributos nuevos que surgen de este trabajo que
hemos profundizado o esta mirada interna de lo que estamos modelando.
Las responsabilidades son correspondencia con mensajes que llegan al objeto, nos aporta al diagrama
que todos los mensajes que llegan al objeto de entidad preciso van a ser responsabilidades de la clase.
Todos los mensajes que llegan al objeto van a ser mensajes que tienen que estar en esa clase.
Entonces concretamente va a ser, yo me voy a ir a cada objeto de entidad y si la responsabilidad ya
esta no hay problema y si no esta la voy agregando. Si hicimos bien el diagrama de comunicación el
diagrama de clases de análisis se hace solo, todo mensaje que llega al objeto de entidad va a ser una
responsabilidad de la clase de ese tipo.
Clase de control
Tiene como toda clase atributos y responsabilidades, lo que
cambia es como la vamos a definir. Esta clase es nueva en
comparación a la de entidad, yo la voy a representar igual que
a las de entidad con nombre, atributo y responsabilidades,
pero la cuestión es pensar que atributos tiene siendo estos
toda la información que maneje ese objeto de control entre las
peticiones que recibe de las clases de interfaz y toda la información que le devuelva como valor de
retorno las clases de entidad. Entonces va a ser toda esa información que maneja para hacer la
realización de esos casos de uso , valores calculados, listas de localidades, barrio que debe mostrar,
fechas obtenidas y toda información que ingrese de la interfaz o que obtenga de los objetos de entidad.
Cada vez que tengamos un diagrama de comunicación y tengamos un objeto de control con un nombre
ese va a ser el nombre de la clase de control. Cada objeto de control va a ser una clase de control.
Cada clase según cada objeto definido y modelado en un diagrama de comunicación y por cada clase
de control voy a tener que definirle atributos y responsabilidades, atributos que pueden ser todos los
que maneje durante la ejecución de ese caso de uso como valores calculados, fechas que obtengo,
números que genere, fecha del sistema, datos a registrar.
El manejador que es un clase de tipo de control cuando empieza la programación y el sistema a
funcionar se abre la pantalla y por detrás el sistema va a estar haciendo acciones, el objeto de control
dura y existe en lo que dura la ejecución en memoria de ese caso de uso que serían esas
funcionalidades y luego desaparece. Estos atributos es lo que nos va a servir de gestión para ejecutar
el caso de uso.
El como se escribe la notación de los atributos y las responsabilidades es igual a lo de entidad. De
esos atributos vamos a tener atributos propios que manejan la relación y en función de los enlaces
que tengan con otras clases serán además atributos de referencia para permitir la relación con otras
Análisis de Sistema Resumen Nicolás Aguirre
clases. Para que esta clase de interfaz pueda mandar mensajes en el objeto control y el objeto control
pueda mandar mensajes a la clase interfaz tiene que existir un atributo de referencia que establezca
ese enlace para poder enviar mensajes.
Además, como es una clase, además de atributos va a tener responsabilidades, que van a ser todos
los mensajes que lleguen a ese objeto entonces dependiendo del objeto será el mensaje recibido, si
yo tengo este objeto de control, todos los mensajes que llegan al objeto son aquellos mensajes que
vienen del objeto de interfaz y todos los mensajes self que se envía a si mismo, entonces esta
responsabilidad no las tenemos que pensar, las registramos en función del diagrama de comunicación.
Siempre todo objeto de una clase y cada clase debe tener la responsabilidad crear que es la creación
de un objeto y en función de los atributos de referencia hay que poner la responsabilidad que permite
que se establezcan las relaciones en función de los enlaces con otras clases.
Clase de interfaz
Como es clase tiene atributos y responsabilidades. La
clase interfaz es la pantalla, impresora, el archivo, los
atributos van a ser que maneje en ese espacio la
ventana o la pantalla, es cada elemento de los
recursos de implementación de esa interfaz.
Tiene la misma forma que las clases anteriores, tiene el nombre de la clase, atributos y
responsabilidades. Vamos a representar tantas como objetos de interfaz tenga cada diagrama de
comunicación. El nombre es el mismo que el diagrama de comunicación, tiene como atributos todos
los elementos que se utilicen en el diseño de la pantalla y además un atributo de referencia en relación
a ese objeto.
De responsabilidades, son todas las que llegan al objeto,
son las que vengan del actor, los self y las que vengan
del objeto de control. Vamos a tener el crear porque toda
clase debe tener el crear y en este caso otra responsabilidad que tenga que ver con la cantidad de
enlaces y a quien envía mensajes este objeto.
Construcción del diagrama de clase de análisis
Análisis de Sistema Resumen Nicolás Aguirre

Resumen de lo visto

Esta es la correspondencia, dentro del flujo de trabajo de requisitos hicimos el modelo de CU que tiene
un diagrama, una descripción y su prototipo y hay una correspondencia completa entre las funciones
de los casos de uso que son requisitos funcionales, la descripción y el prototipo con toda la estructura
que sustenta que es el modelo de objetos del dominio. Cuando uno hace este trabajo de ingeniería de
requerimientos ha hecho todo este esfuerzo de plantear la propuesta de sistema, identificar el listado
de requerimientos funcionales y no funcionales y luego trabajar todo lo que es el planteo de esa
propuesta con lo que es la especificación de ese requerimiento construyendo el modelo de casos de
uso y el modelo del dominio.
Conforme uno avanza con el flujo de trabajo de análisis va a construir un conjunto de nuevos
diagramas con la mirada interna y con todo el propósito que tiene ese flujo de trabajo de análisis que
va a valerse de la construcción de alguna serie de diagramas de interacción como el de comunicación
y el diagrama de clases de análisis donde existe una correspondencia completa con que yo voy a
hacer un diagrama de comunicación partiendo de un caso de uso con su descripción y prototipo, voy
a ir identificando como los objetos colaboran entre si partiendo de los objetos que pertenecen a las
clases de entidad del modelo de objetos del dominio y luego se construye el diagrama de clases de
análisis partiendo del modelo de objetos del dominio con la consideración del diagrama de
comunicación de cada caso de uso modelado y voy haciendo la construcción completa y encontrando
las nuevas clases del diagrama de clases de análisis.