Please enable JavaScript.
Coggle requires JavaScript to display documents.
Comprensión y modelado de los sistemas organizacionales, 15 (2), 1, 3, 4,…
Comprensión y modelado de
los sistemas organizacionales
Capacidad de interrelación e interdependencia de los sistemas
Este hecho tiene implicacionesimportantes,tanto para las organizaciones como para los analistas de sistemas que buscan ayudar a estas organizacionesa cumplir mejor sus objetivos.
Organizaciones y equipos virtuales
Les permitan modificar sus configuraciones para adaptarse a las demandas cambiantes del proyecto o del mercado.
Una perspectiva de sistemas
Al tomar una perspectiva de sistemas,los analistas pueden empezar a descifrar y comprender en términos generales las diversas empresas con las que entrarán en contacto.
Sistemas empresariales
Se denominan sistemas de planificación de recursos empresariales (ERP), constituyen un término empleado para describir un sistema de información organizacional
MRP
La planificación de requerimientos de materiales (MRP), sistemas de información diseñados para mejorar el proceso de manufactura en general y el proceso de ensamblaje.
Descripcion grafica de los sistemas
Los diversos modelos gráficos muestran los límites del sistema y la información que utiliza.
Los sistemas y el diagrama de flujo de datos
También conocido como modelo ambiental, los diagramas de flujo de datos se enfocan en los datos que fluyen hacia el sistema y salen de él,además del procesamiento de estos datos.
Los sistemas y el modelo de entidad-relación
Los elementos que conforman un sistema organizacional
se pueden denominar entidades.
Una entidad puede ser una persona, un lugar o una cosa, como un pasajero en una aerolínea, un destino o un avión. O bien, una entidad puede ser un evento, como el fin de mes.
Para realizar un diagrama E-R se necesia
Enlistar las entidades en la organización para obtener una mejor comprensión de la misma.
Elegir las entidades clave para reducir el alcance del problema a una dimensión manejable y significativa
Identificar cuál debe ser la entidad principal.
Confirmar los resultados de los pasos 1 al 3 por medio de otros métodos de recopilación de datos
MODELADO DE CASOS DE USO
Un diagrama para usarlo en el UML orientado a objetos, ahora los casos de uso se utilizan sin importar la metodología para el desarrollo de sistemas.
Símbolos de los casos de uso
Un diagrama de caso de uso contiene los símbolos del actor y del caso de uso, junto con líneas conectoras.
Relaciones de los casos de uso
Las relaciones activas se conocen como relaciones de comportamiento y se utilizan principalmente en los diagramas de casos de uso
Tipos básicos de relaciones de comportamiento:
Comunica para conectar un actor con un caso de uso se utiliza una línea sin puntas de flecha.
Incluye un caso de uso contiene un comportamiento común para más de un caso de uso. La flecha apunta al caso de uso común.
Extiende un caso de uso distinto maneja las excepciones del caso de uso básico. La flecha apunta del caso de uso extendido al básico.
Generaliza una “cosa” de UML es más general que otra “cosa”. La flecha apunta a la “cosa” general.
Desarrollo del alcance del sistema
El alcance de un sistema define sus límites, lo que está al alcance (dentro del sistema) y lo que está fuera de él.
Desarrollo de diagramas de casos de uso
El caso de uso principal consiste en un flujo estándar de eventos que describe un comportamiento estándar del
sistema.
Lineamientos
Revise las especificaciones de negocios e identifique a los actores involucrados.
Identifique los eventos de alto nivel y desarrolle los casos de uso principales que describen a esos eventos
junto con la forma en que los actores los inician.
Revise cada caso de uso principal para determinar las posibles variaciones del flujo a través del caso de uso.
Desarrollo de escenarios de casos de uso
Designaremos a la descripción como un escenario de caso de uso. El caso de uso principal representa el flujo estándar de eventos en el sistema y las rutas alternativas describen variaciones sobre el comportamiento.
Los escenarios de casos de uso pueden describir lo que ocurre al comprar un artículo agotado, o si una empresa de tarjetas de crédito rechaza la compra solicitada por un cliente.
Niveles de los casos de uso
Blanco es el nivel más alto, al igual que las nubes. Éste es el nivel empresarial y puede haber sólo cuatro o
cinco para toda la organización.
El cometa es inferior al blanco, pero sigue siendo un nivel alto que ofrece una visión general.
Azul está a nivel del mar, y por lo general se crea para los objetivos de los usuarios.
Índigo o pez es un caso de uso que muestra muchos detalles, a menudo a un nivel funcional o subfuncional.
Negro o almeja, como en el fondo del océano. Éstos son los casos de uso más detallados, a un nivel de subfunción.
Las tres áreas principales son:
Un encabezado de área que contiene los identificadores e iniciadores del caso.
Los pasos realizados.
Un área de pie de página que contiene precondiciones, suposiciones, preguntas y demás información relacionada.
Por qué son útiles los diagramas de casos de uso
Sin importar el método que utilice para desarrollar su sistema (métodos SDLC tradicionales, métodos ágiles o
métodos orientados a objetos),
Las acciones a completar también se muestran con claridad en el diagrama de caso de uso
El escenario del caso de uso siempre es algo que vale la pena.
Los diagramas de caso de uso se están haciendo populares debido a su sencillez y carencia de detalles técnicos.
NIVELES DE ADMINISTRACIÓN
• Los casos de uso comunican los requerimientos del sistema con efectividad, ya que los
diagramas se mantienen simples.
• Los casos de uso permiten a las personas contar historias.
• Las historias de los casos de uso tienen sentido para las personas sin conocimientos técnicos.
• Los casos de uso no dependen de un lenguaje especial.
• Los casos de uso pueden describir la mayoría de los requerimientos funcionales (como las
interacciones entre los actores y las aplicaciones).
• Los casos de uso pueden describir los requerimientos no funcionales (como el rendimiento
y la capacidad de mantenimiento) a través del uso de estereotipos.
• Los casos de uso ayudan a los analistas a definir los límites.
• Los casos de uso se pueden rastrear para que los analistas puedan identificar los enlaces
entre los casos de uso y otras herramientas de diseño y documentación.
Implicaciones para el desarrollo de sistemas de información
Los gerentes de operaciones necesitan información interna de naturaleza repetitiva y bajo nivel.
En el siguiente nivel administrativo, los gerentes de nivel medio necesitan información de corto y largo plazos.
Los gerentes estratégicos difieren un poco de los gerentes de nivel medio y de operaciones en cuanto a sus
requerimientos de información.
Creación de las descripciones de los casos de uso
Use historias ágiles, los objetivos de la definición del problema, requerimientos de los usuarios o una lista de
características como punto de inicio.
Pregunte sobre las tareas que hay que realizar para lograr la transacción. Pregunte si el caso de uso lee datos
o actualiza alguna tabla.
Averigüe si hay acciones iterativas o de ciclos.
El caso de uso termina cuando se completa el objetivo del cliente.
