Resumen Análisis de Sistemas

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.
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
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.
- 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.
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.
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.
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ás.Pero 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:
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.
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.
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 (RR.HH.) 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
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.
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.
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:
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
- 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.
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).
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.
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:
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
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.
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.
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.
Siendo la definición de cada uno de ellos:

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.
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.
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
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.
.
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.
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,
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á
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.
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
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

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.
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
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.
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.
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
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.
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
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
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.
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
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.
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.

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
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.
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
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 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.
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
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).
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.
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.
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.
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:

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.
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.
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
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.
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.
Otras consideraciones
Estructura de UML
En esa estructura se define:
Siendo:
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í.
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()”.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.

Resumen Análisis de Sistemas - Unidades 1-2-3

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Resumen Análisis de Sistemas - Unidades 1-2-3

Cargado por

Copyright:

Formatos disponibles

Análisis de Sistema Resumen Nicolás Aguirre

Cliente del proceso

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

Siendo la definición de cada uno de ellos:

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

Cuatro P de la ingeniería de software

Tipos de modelos descriptivos

Modelo de procesos evolutivos

La más usada en el mercado es SCRUM.

Análisis de factibilidad de un proyecto

El estado está representado por los

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

Relaciones entre clases

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

Modelados del dominio

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

También podría gustarte