Realizar Sugerencias

Deje su comentario, consulta o bug, estamos trabajando para realizar un mejor servicio.



Resumen ASI - UTN FRC - Sistemas - [Post Plata]

(Resúmenes)

Resumen ASI

Debe iniciar sesión para votar

UNIDAD Nº 1

“LOS SISTEMAS DE INFORMACIÓN”

 

 

DATOS E INFORMACIÓN

 

Los datos son realidades concretas en su estado primario; poseen escaso valor más allá del propio. La información es un conjunto de datos organizados de tal modo que adquieren un valor adicional más allá del propio.

El tipo de información creada depende de las relaciones definidas entre los datos existentes.

La conversión de datos en información es un proceso o serie de tareas lógicamente relacionadas entre sí y ejecutadas con el fin de producir un resultado definido. El proceso para definir relaciones entre datos requiere de conocimiento.

 

Características de la información

 

·         Exacta: carece de errores.

·         Completa: contiene todos los datos importantes.

·         Económica

·         Flexible: es útil para muchos propósitos.

·         Confiable: depende del método de recolección de datos y de la fuente de información.

·         Pertinente: es la realmente importante.

·         Simple: no debe ser excesivamente compleja.

·         Oportuna: es la que se recibe justo cuando se la necesita.

·         Verificable: posibilidad de comprobar que es correcta.

·         Accesible: debe ser de fácil acceso para los usuarios autorizados.

·         Segura: debe estar protegida contra el acceso a ella de usuarios no autorizados.

 

SISTEMAS DE INFORMACIÓN

 

Un SI es un conjunto de elementos o componentes interrelacionados para recolectar (entrada), manipular (proceso), y diseminar (salida) datos e información y para proveer un mecanismo de retroalimentación en pro del cumplimiento de un objetivo.

 

Entrada

 

La entrada es la actividad que consiste en recopilar y capturar datos primarios. Puede ser un proceso manual o automatizado.

 

Procesamiento

 

El procesamiento supone la conversión o transformación de datos en salidas útiles. Esto puede implicar ejecutar cálculos, realizar comparaciones y adoptar acciones alternas, y el almacenamiento de datos para su uso posterior.

El procesamiento puede llevarse a cabo de manera manual o con la asistencia de computadoras.

 

Salida

 

La salida implica producir información útil, por lo general en forma de documentos y/o reportes.

A menudo es común que la salida de un sistema sirva como entrada para el control de otros sistemas o dispositivos.

 

Retroalimentación

 

La retroalimentación es la salida que se utiliza para efectuar cambios en actividades de entrada o procesamiento. La presencia de errores o problemas podría imponer la necesidad de corregir datos de entrada o modificar un proceso.

 

SI MANUALES Y COMPUTARIZADOS

 

Un SI puede ser manual o computarizado.

Muchos SI son inicialmente sistemas manuales que después se convierten en sistemas computarizados.

Sin embargo, conviene señalar que la simple computarización de un sistema manual no garantiza un mejor desempeño. Si el sistema original es defectuoso, bien podría ocurrir que al ser computarizado no se consiguiera más que magnificar el impacto de esos errores.

 

SI BASADOS EN COMPUTADORAS

 

Un SIBC está compuesto por hardware, software, bases de datos, telecomunicaciones, personas, y procedimientos específicamente configurados para recolectar, manipular, almacenar y procesar datos para ser convertidos en información.

A los SIBC también se le conoce como infraestructura tecnológica de una compañía, porque constituyen los recursos compartidos de SI que sirven de fundamento a los sistemas de información.

 

Hardware: es el equipo de computación que se utiliza para llevar a cabos las actividades de entrada, procesamiento y salida.

 

Software: está constituido por los programas de computación que dirigen las operaciones de una computadora.

 

Bases de datos: es un conjunto organizado de datos e información.

 

Telecomunicaciones, redes e Internet: las telecomunicaciones son la transmisión electrónica de señales de comunicación que permiten a las organizaciones conectar entre sí sistemas de computación para integrar redes. Las redes sirven para enlazar computadoras y equipo de computación con la finalidad de establecer comulaciones electrónicas.

La Internet es la red de computación más grande del mundo; consiste en miles de redes interconectadas, las cuales intercambian libremente información.

 

Personas: son el elemento más importante de la mayoría de los SIBC. El personal de sistemas de información incluye a todos los individuos que administran, operan, programan y mantienen el sistema. Los usuarios son aquellos que utilizan sistemas de información para obtener resultados. Ejemplos:

ü  Líder del proyecto.

ü  Usuario.

ü  Administrador: da los recursos para la realización del sistema.

ü  Analista: crea los modelos de la solución a los requerimientos del usuario.

ü  Diseñador: dice de qué modo hay que construir el sistema.

ü  Desarrollador: codifica el sistema.

ü  Operador: realiza la carga de datos.

ü  Tester: prueba el sistema.

 

Procedimientos: son las estrategias, políticas, métodos y reglas para el uso del SIBC. Los procedimientos describen en qué momento efectuar un programa, quién puede tener acceso a la información de la base de datos, qué debe hacerse en caso de desastre, en cuyos casos el SIBC sea inutilizable.

 

SI EN LAS EMPRESAS

 

Sistemas de procesamiento de transacciones (TPS)

Un TPS (o sistema transaccional) es un conjunto organizado de personas, procedimientos, software, bases de datos y dispositivos para registrar las transacciones comerciales consumadas. Se dedica al tratamiento de las operaciones rutinarias diarias (transacciones).

Una transacción es todo intercambio relacionado con las actividades de una empresa.

Conocer un TPS es conocer las operaciones y funciones básicas de las compañías.

 

Comercio electrónico

El comercio electrónico comprende todas las transacciones de negocio ejecutadas por medios electrónicos entre compañías (empresa-empresa), compañías y consumidores (empresa-cliente), compañías y sector público, y consumidores y sector público.

 

Sistemas de información administrativa (MIS)

Un MIS es un conjunto organizado de personas, procedimientos, software, bases de datos y dispositivos para suministrar información rutinaria a administradores y tomadores de decisiones.

Los MIS suelen producir informes estándar generados con base de datos e información procedente del TPS.

 

Sistemas de apoyo para la toma de decisiones (DSS)

Un DSS es un conjunto organizados de personas, procedimientos, software, bases de datos y dispositivos para el apoyo en la toma de decisiones referentes a problemas específicos.

Mientras que un MIS contribuye a que una organización “haga correctamente las cosas”, un DSS ayuda a los administradores a “hacer las cosas correctas”.

Un DSS sirve de base y fuente de ayuda ara todos los aspectos de la toma de decisiones referentes a problemas específicos. Por tanto, su espectro es mayor que el de un MIS; es capaz de ofrecer asistencia inmediata para resolver problemas complejos respecto de los cuales un MIS carecería de utilidad.

 

 

INTELIGENCIA ARTIFICIAL Y SISTEMAS EXPERTOS

 

Además de contar con TPS, MIS y DSS, las organizaciones también suelen servirse de sistemas basados en la noción de la inteligencia artificial (IA), los cuales adoptan características propias de la inteligencia humana.

La robótica es el área de la IA donde máquinas ejecutan tareas complejas, rutinarias o tediosas. Los sistemas de visión dotan de “vista” a robots y otros dispositivos. El procesamiento del lenguaje natural implica la facultad de las computadoras para comprender y responder a órdenes. Los sistemas de aprendizaje habilitan a las computadoras para aprender de la experiencia o de sus errores. Las redes neuronales son una rama de la IA que permite a las computadoras reconocer patrones o tendencias y actuar en consecuencia. Y los sistemas expertos facultan a las computadoras para hacer sugerencias y proceder a la manera de expertos en un campo particular.

 

 

DESARROLLO DE SISTEMAS

El desarrollo de sistemas es la actividad destinada a crear sistemas o a modificar los ya existentes en uso en las empresas. El desarrollo de SI para satisfacer las necesidades administrativas es una tarea sumamente compleja y difícil.

 

Investigación de sistemas

El objetivo de la investigación de sistemas es obtener un conocimiento claro del problema por resolver o de la oportunidad por aprovechar.

 

Análisis de sistemas

Consiste en definir los problemas y oportunidades que el sistema existente ofrece.

 

Diseño de sistemas

Es la determinación del modo en que operará el nuevo sistema para satisfacer las necesidades de la empresa definidas durante el análisis.

 

Implementación de sistemas

Es la creación o adquisición de los diversos componentes de sistemas (hardware, software, bases de datos, etc.) definidos en el paso de diseño, su respectivo montaje y puesta en operación del nuevo sistema.

 

Mantenimiento y revisión de sistemas

Es la inspección y modificación del sistema para que siga satisfaciendo las cambiantes necesidades de la empresa.

 

CAPACITACIÓN EN SISTEMAS COMPUTACIONALES Y DE INFORMACIÓN

 

La capacitación computacional es el conocimiento de los sistemas y equipo de computación y su funcionamiento.

La capacitación en sistemas de información es el conocimiento del uso que individuos, grupos y organizaciones hacen de datos e información.

Saber como poner en funcionamiento TPS’s, MIS’s, DSS’s y sistemas expertos para cumplir las metas de una organización es uno de los aspectos esenciales de la capacitación en sistemas de información.

SISTEMAS DE PROCESAMIENTO DE TRANSACCIONES (TPS)

 

Las transacciones son operaciones básicas de negocio tales como pedidos de clientes, solicitudes de compras, recepciones, tarjetas de registro de tiempos, facturas y cheques de nóminas de una organización.

Toda organización tiene sistemas de procesamiento de transacciones (TPS) manuales o automáticos, que procesan los datos detallados necesarios para actualizar los registros que tienen relación con las operaciones de negocios fundamentales de la organización.

Las entradas a estos sistemas incluyen transacciones básicas de negocio.

El resultado de procesar transacciones de negocio es que los registros de la organización se actualizan para reflejar la situación de la operación al momento de la última transacción procesada.

El procesamiento incluye la recopilación, edición, corrección, manipulación y almacenamiento de datos y la producción de documentos.

En la mayor parte de las organizaciones los TPS dan soporte a las actividades rutinarias.

 

Métodos y objetivos tradicionales del procesamiento de transacciones

 

Todas la transacciones ser reunían en grupos, denominados “lotes” y se procesaban juntos. Con los sistemas de procesamiento por lotes las operaciones de negocio se acumulaban por un período y se preparaban para procesarse como una sola unidad o lote.

La característica esencial de un sistema de procesamiento por lotes es que se produce alguna demora entre el momento en que ocurre el acto y el posterior procesamiento de la transacción relacionada para actualizar los registros de la organización.

La tecnología de computación actual permite otro método de procesamiento denominado procesamiento en línea, de tiempo real o procesamiento de transacciones en línea. Con esto, cada transacción se procesa de inmediato. Tan pronto se cuenta con la información de entrada, un programa de computación realiza el procesamiento necesario y actualiza los registros implicados en esa transacción individual. Por consiguiente, los datos en un sistema en línea en cualquier momento presentan la situación actual.

Un tercer tipo de procesamiento de transacciones, denominado entrada en línea con procesamiento retardado, es un intermedio entre los procesamiento por lotes y en línea. Con este tipo de sistema, las transacciones se introducen al sistema de computación al momento en que ocurren, pero no se procesan de inmediato.

 

Los objetivos específicos de la organización definen el método de procesamiento de las transacciones más conveniente para las diversas aplicaciones de la compañía.

Las compañías esperan que sus TPS logren varios objetivos específicos:

·         Procesar datos generados por las transacciones y que se relacionen con ellas.

·         Mantener un alto grado de exactitud.

·         Asegurar la integridad y la exactitud de los datos y la información.

·         Elaborar documentos e informes oportunos.

·         Aumentar la eficiencia de la mano de obra.

·         Ayudar a proporcionar mayores y mejores servicios.

·         Ayudar a crear y mantener la lealtad del cliente.

·         Lograr una ventaja competitiva.

 

Actividades del procesamiento de transacciones

 

Los TPS capturan y procesan datos que describen transacciones de negocio fundamentales.

Los datos de negocio pasan a través de un ciclo de procesamiento de transacciones que consta de las siguientes actividades:

 

Recopilación de datos: es el proceso mediante el cual se capturan los datos necesarios para completar las transacciones.

 

Edición de datos: es el proceso mediante el cual se busca la validez e integridad de los datos a fin de detectar cualquier problema con ellos.

 

Corrección de datos: implica volver a introducir los datos mal capturados que se localizaron durante la edición.

 

Manipulación de datos: es el proceso de realizar cálculos y otras transformaciones de los datos que tienen relación con transacciones de negocio.

 

Almacenamiento de datos: consiste en actualizar una o más bases de datos con nuevas transacciones.

 

Elaboración de documentos: consiste en generar registros e informes de salidas.

 

PLANEACIÓN DE RECURSOS DE LA EMPRESA (ERP)

 

El acceso a la información con la mayor rapidez posible puede ayudar a las empresas a dar mejor servicio a sus clientes, elevar los estándares de calidad y evaluar las condiciones de mercado. La ERP es un factor básico para el acceso instantáneo.

El elemento fundamental de la ERP es la supervisión en tiempo real de las funciones de la empresa.

Un software ERP es una aplicación de gestión empresarial que da soporte a las distintas áreas funcionales de la empresa.

 

Ventajas del sistema ERP

 

·         Eliminación de sistemas ineficientes.

·         Facilitamiento de la adopción de mejores procesos de trabajo.

·         Mejoramiento del acceso a los datos.

·         Estandarización de la tecnología.

 

Desventajas del sistema ERP

 

·         Requiere tiempo.

·         Es complicado y costoso de poner en marcha.

 

 

 

 

SI BÁSICOS EN LAS EMPRESAS

 

Una empresa típica cuenta con una estructura de SI compuesta por los siguientes subsistemas:

·              Subsistema de RR.HH

·              Subsistema de gestión contable y financiero.

·              Subsistema de gestión comercial y de marketing.

·              Subsistema de control de las existencias y de producción.

 

Subsistema de RR.HH

 

Las actividades de gestión relacionadas con el personal de la empresa se basan en dos aspectos:

  1. La gestión de la información relacionada con la plantilla: esta información incluye:
    • Filiación completa.
    • Datos médicos.
    • Historia laboral.
    • Salario e incentivos.
    • Carrera profesional e historial formativo de los empleados.

 

  1. La ejecución de la nómina: la relación de pagos salariales se realiza en forma periódica. Para determinar todos los conceptos de la paga de cada empleado, se debe disponer de sus datos contractuales, así como el historial laboral en el período, etc.

 

 

 

Subsistema de gestión comercial

 

Las actividades de gestión relacionadas con el trato con los clientes se basan en dos áreas principales:

  1. Las propias ventas:
    • La gestión y tratamiento de los pedidos.
    • La facturación de la venta o pedido.
    • El control de los detalles de entrega y la actualización del inventario.

 

  1. La función de comercialización: implica el análisis de las ventas, de la competencia, de los gustos y demanda de los clientes, etc. para optimizar todos loas aspectos que intervienen en la implantación de productos en el mercado.

 

Subsistema de gestión contable y financiera

 

La gestión contable diaria implica hacer frente a ciertas funciones clásicas:

·              Gestión de libro mayor.

·              Control de activos fijos.

·              Gestión de cobros y ventas.

·              Gestión de pagos y cuentas por pagar.

·              Control de inventario y de su coste.

·              Gestión de compras.

·              Ejecución de la nómina.

·              Generación de informes para la dirección.

 

Subsistema de control de almacén y producción

 

El objetivo principal de un sistema de gestión de inventario y de producción es el control de las existencias almacenadas y el desarrollo de la producción.

Algunas actividades son:

·         Compras de MP o componentes.

·         Envío de productos fabricados a clientes.

·         Información de control de calidad de MP y productos.

·         Planificación de la capacidad de producción.

 

Otros subsistemas

Existen otros subsistemas básicos:

·         Sistemas de automatización de oficinas: es el conjunto de ayudas necesarias para realizar el trabajo esencial de oficina: procesadores de texto, correo electrónico, agendas, hojas de cálculo, etc.

 

·         Sistemas de producción: incluyen la automatización de fabricación y las ayudas para el diseño y puesta en producción de productos.


UNIDAD Nº 2

“PROCESO DE DESARROLLO DE SOFTWARE”

 

 

INGENIERÍA DEL SOFTWARE

 

La ingeniería del software es la aplicación de un enfoque sistemático, disciplinado y cuantificable hacia el desarrollo, operación y mantenimiento del software; es decir, es la aplicación de ingeniería al software.

La ingeniería del software es una tecnología multicapa.

 

 

La base de la ingeniería del software está orientada hacia la calidad.

El fundamento de la ingeniería del software es la capa proceso. El proceso define un marco de trabajo que debe establecerse para la entrega efectiva de la tecnología de la ingeniería del software.

Los métodos indican cómo construir técnicamente el software. Abarcan una gran gama de tareas que incluyen el análisis de requisitos, diseño, construcción de programas, pruebas y mantenimiento. Incluyen actividades de modelado y otras técnicas descriptivas.

Las herramientas proporcionan un soporte automático o semi-automático para el proceso y para los métodos.

 

Una visión general de la ingeniería del software

 

La ingeniería es el análisis, diseño, construcción, verificación y gestión de entidades técnicas.

El trabajo que se asocia a la ingeniería del software se puede dividir en tres fases genéricas:

·         Fase de definición: se centra en el qué. Se intenta identificar qué información ha de ser procesada, qué función y rendimiento desea, qué comportamiento del sistema, qué interfaces van a ser establecidas, qué restricciones de diseño existen, y qué criterios de validación se necesitan para definir un sistema correcto. Tendrán lugar tres tareas principales: ingeniería de sistemas o de información, planificación del proyecto de software y análisis de los requisitos.

 

·         Fase de desarrollo: se centra en el cómo. Se intenta definir cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función, cómo han de caracterizarse las interfaces, cómo ha de traducirse el diseño en u lenguaje de programación y cómo ha de realizarse la prueba. Hay tres tareas específicas: diseño del software, generación de código y prueba del software.

 

·         Fase de mantenimiento: se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas a medida que evoluciona el entorno del software y a cambios debidos a las mejoras producidas por los requisitos cambiantes del cliente. Durante esta fase se encuentran cuatro tipos de cambios:

ü  Corrección.

ü  Adaptación.

ü  Mejora.

ü  Prevención (reingeniería del software).

 

EL PROCESO DEL SOFTWARE

 

En este proceso se establece un marco común del proceso, definiendo un pequeño número de actividades del marco de trabajo. Un conjunto de tareas que permiten que las actividades del marco de trabajo se adapten a las características del proyecto del software y a los requisitos del equipo del proyecto. Se definen por último las actividades de protección, que son independientes de cualquier actividad del marco de trabajo y aparecen durante todo el proceso.

La calidad del proceso de software brinda calidad al producto final. Una empresa certificada en calidad, es una empresa confiable.

 

Niveles de madurez de un proceso de software

 

1.      Inicial: procesos impredecibles – pobremente controlados – reactivos.

2.      Administrado: procesos caracterizados por proyectos – es a menudo reactivo.

3.      Definido: procesos caracterizados por la organización – son preactivos.

4.      Cuantitativamente administrado: procesos medidos y controlados.

5.      Optimizado: foco en la mejora de procesos.

 

 

 

MODELOS DE PROCESO DE SOFTWARE

 


MODELO DE PROCESO

DESCRIPCIÓN

ETAPAS

VENTAJAS

DESVENTAJAS

Modelo lineal secuencial

Sugiere un enfoque sistemático, secuencial del desarrollo del software que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación.

 

 

 

 

 

 

 

 

 

 

 

Ingeniería y modelado de Sistemas / Información: el trabajo comienza estableciendo requisitos de todos los elementos del sistema y asignando al software algún subgrupo de estos requisitos.

Análisis de los requisitos de software: el proceso de reunión de requisitos se intensifica y se centra en el software. El cliente documenta y repasa los requisitos del sistema y del software.

Diseño: se centra en cuatro atributos de un programa: estructura de datos, arquitectura de software, representaciones de interfaz y detalle procedimental.

Generación de código: el diseño se debe traducir en una forma legible por la máquina.

Pruebas: se centra en los procesos lógicos internos del software, asegurando que las sentencias se han comprobado, y en los procesos externos funcionales.

Mantenimiento: vuelve a aplicar cada fase a un programa existente.

 

 

 

• Tiene un lugar definido e importante en el trabajo de la ingeniería del software.

• Proporciona una plantilla en la que se encuentran métodos para análisis, diseño, codificación, pruebas y mantenimiento.

• Es mejor que un enfoque hecho al azar.

• Los proyectos reales raras veces siguen el modelo secuencial. Los cambios pueden causar confusión cuando el equipo del proyecto comienza.

• Es difícil que el cliente exponga explícitamente todos los requisitos; y el modelo secuencial lo requiere.

• Una versión del trabajo del programa no estará disponible hasta que el proyecto esté muy avanzado.

• La naturaleza lineal del ciclo de vida clásico lleva a estados de bloqueo.

MODELO DE PROCESO

DESCRIPCIÓN

ETAPAS

VENTAJAS

DESVENTAJAS

Modelo de construcción de prototipos

Propone crear un 

prototipo del sistema

para que los

desarrolladores puedan  identificar los requisitos  del software y el cliente  pueda tener una idea de  cómo será el producto final.

Recolección de requisitos: el desarrollador y el cliente encuentran y definen los objetivos globales para el software, identifican los requisitos conocidos, y las áreas del esquema donde es obligatoria más definición.

Diseño rápido: el diseño rápido se centra en una representación de esos aspectos del software que serán visibles para el usuario / cliente.

Construcción de prototipos: el prototipo lo evalúa el cliente / usuario y lo utiliza para refinar los requisitos del software a desarrollar.

• Es útil cuando el cliente define un conjunto de objetivos generales para el software, pero no identifica los requisitos detallados de entrada, procesamiento o salida.

• Sirve cuando el responsable del desarrollo del software puede no estar seguro de la eficiencia de un algoritmo, de la capacidad de adaptación de un sistema operativo, o de la forma en que debería tomarse la interacción hombre-máquina.

• Cuando se informa de que el producto se debe construir otra vez para que se puedan mantener los niveles altos de calidad, el cliente no lo entiende y pide que se apliquen “unos pequeños ajustes” para que se pueda hacer del prototipo un producto final. De forma demasiado frecuente la gestión de desarrollo de software es muy lenta.

• El desarrollador a menudo hace compromisos de implementación para hacer que el prototipo funcione rápidamente. La selección menos ideal ahora es una parte integral del sistema.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

MODELO DE PROCESO

DESCRIPCIÓN

ETAPAS

VENTAJAS

DESVENTAJAS

Modelo de Desarrollo Rápido de Aplicaciones (DRA)

Es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto.

Modelado de Gestión: se modela el flujo de información para responder, qué información conduce el proceso, qué información y quién la genera, a donde se dirige y quién la procesa.

Modelado de datos: se definen las características de cada objeto de dato y la relación con los otros objetos.

• Modelado del proceso: la descripción del proceso, se utiliza para añadir, modificar, suprimir o recuperar un objeto de datos.

Generación de aplicaciones: se utilizan herramientas automáticas para facilitar la construcción del software.

Pruebas y entrega: se deben comprobar todos los componentes nuevos y se deben ejercitar todas las interfaces.

 

 

 

 

 

 

 

 

 

 

• DRA enfatiza el desarrollo de componentes de programas reutilizables. La reutilización, es la piedra angular de las tecnologías de objeto.

• Para proyectos grandes se requieren recursos humanos suficientes para crear el número correctos de equipos DRA.

• Requiere clientes y desarrolladores comprometidos en las rápidas actividades necesarias para completar un sistema en un marco de tiempo abreviado.

• No todos los tipos de aplicaciones son apropiados para DRA.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

MODELO DE PROCESO

DESCRIPCIÓN

ETAPAS

VENTAJAS

DESVENTAJAS

Modelo incremental

Combina elementos del modelo lineal secuencial con la filosofía interactiva de construcción de prototipos. Cada secuencia lineal produce un incremento del software, paralelamente con el progreso del tiempo en el calendario. Es interactivo.

 

• El primer incremento por lo general es un producto esencial (núcleo). El cliente utiliza el producto central, obteniendo un resultado de utilización y/o evaluación.

• Para el incremento siguiente se desarrolla un plan que afronta la modificación del producto central a fin de cumplir mejor las necesidades del cliente, y la entrega de funciones, y características adicionales.

• Este proceso se repite siguiendo la entrega de cada incremento, hasta que elabore el producto completo.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

• Se centra en la entrega de un producto operacional con cada incremento.

• Proporciona una plataforma para la evaluación por parte del usuario.

• Los primeros incrementos se pueden implementar con poca cantidad de personal y luego si el producto central es bien recibido, y en caso que se requiera, se añade más personal para implementar el incremento siguiente.

• Los incrementos se pueden planear para gestionar riesgos técnicos.

 

• En el primer incremento, se afrontan requisitos básicos, pero muchas funciones suplementarias quedan sin extraer.

• No es recomendable para casos de sistemas de tiempo real, de alto nivel de seguridad, de procesamiento distribuido, y/o de alto índice de riesgos.

 

MODELO DE PROCESO

DESCRIPCIÓN

ETAPAS

VENTAJAS

DESVENTAJAS

Modelo en espiral

Es un modelo de proceso de software evolutivo que acompaña la naturaleza interactiva de construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal secuencial. El software se desarrolla en una serie de versiones incrementales. Durante las primeras iteraciones, la versión incremental podría ser un modelo en papel o un prototipo. Durante las últimas iteraciones, se producen versiones cada vez más completas de ingeniería del sistema.

Cuando empieza este proceso evolutivo, el equipo de ingeniería del software gira alrededor de la espiral en la dirección de las agujas del reloj, comenzando por el centro. El primer circuito de la espiral produce el desarrollo de una especificación de productos; los pasos siguientes en la espiral se podrían utilizar para desarrollar un prototipo y progresivamente versiones más sofisticadas del software.

 

 

 

Comunicación con el cliente: las tareas requeridas para establecer comunicación entre el desarrollador y el cliente.

Planificación: las tareas requeridas para definir recursos, el tiempo y otras informaciones relacionadas con el proyecto.

Análisis de riesgos: las tareas requeridas para evaluar riesgos técnicos y de gestión.

Ingeniería: las tareas requeridas para construir una o más representaciones de la aplicación.

Construcción y adaptación: las tareas requeridas para construir, probar, instalar y proporcionar soporte al usuario.

Evaluación del cliente: las tareas requeridas para obtener la reacción del cliente según la evaluación de las representaciones del software creadas durante la etapa de ingeniería e implementada durante la etapa de instalación.

 

• Proporciona el potencial para el desarrollo rápido de versiones incrementales del software.

• Puede adaptarse y aplicarse a lo largo de la vida del software de computadora (el proceso no termina cuando se entrega el software).

• Hay veces en que el proceso está inactivo, pero siempre que se inicie un cambio, el proceso arranca en el punto de entrada adecuado.

• Es un enfoque realista del desarrollo de sistemas y de software a gran escala.

• Refleja de forma más realista el mundo real.

• Utiliza la construcción de prototipos como mecanismo de reducción de riesgos.

• Permite a quien lo desarrolla aplicar el enfoque de construcción de prototipos en cualquier etapa de evolución del producto.

• Si se aplica adecuadamente, debe reducir los riesgos antes de que se conviertan en problemáticos.

 

• Puede resultar difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.

• Requiere una considerable habilidad para la evaluación del riesgo.

• Si un riesgo importante no es descubierto y gestionado, indudablemente surgirán problemas.

• El modelo es relativamente nuevo y no se ha utilizado tanto como los paradigmas lineales secuenciales o de construcción de prototipos.

• Tendrán que pasar muchos años antes de que se determine con absoluta certeza la eficacia de este nuevo e importante paradigma.

 

MODELO DE PROCESO

DESCRIPCIÓN

ETAPAS

VENTAJAS

DESVENTAJAS

Modelo de ensamblaje de componentes

Incorpora características del modelo en espiral.

Es evolutivo y exige un enfoque interactivo.

Identificación de clases candidatas: se deben examinar los datos y el algoritmo a aplicar, los cuales se empaquetan en una clase.

• Si las clases candidatas ya existen en una biblioteca de clases se extraen y se vuelven a utilizar, de lo contrario, se aplican los métodos orientados a objetos.

• Se introduce la iteración ensambladora de componentes a través de la actividad de ingeniería.

 

• Lleva a la reutilización del software y esto proporciona beneficios.

• Lleva a una reducción del 70% de tiempo de ciclo de desarrollo y un 84% de costo del proyecto.

• Necesidad de habilidades mucho mayores por parte del equipo de diseño.

Modelo de desarrollo concurrente

Define una serie de acontecimientos que dispararán transiciones de estado a estado para cada una de las actividades de la ingeniería del software.

Dimensión de sistemas:

• Diseño

• Ensamblaje

• Uso

 

Dimensión de componentes:

• Diseño

• Realización

 

La concurrencia se logra de dos formas:

• Las actividades de sistemas y de componentes ocurren al mismo tiempo.

• Una aplicación cliente/servidor se implementa con muchos componentes, los cuales se pueden realizar concurrentemente

 

 

•  Es aplicable a todo tipo de desarrollo de software.

• Proporciona una imagen del estado actual e un proyecto.

• Define una red de actividades, las cuales actúan simultáneamente.

 

• Si no existen grupos de trabajo no se puede trabajar en este método.

MODELO DE PROCESO

DESCRIPCIÓN

ETAPAS

VENTAJAS

DESVENTAJAS

Modelo de métodos formales

Permite que se especifique, desarrolle y verifique un sistema basado en computadora aplicando una notación rigurosa y matemática.

 

•  Métodos basados en álgebra de procesos: modelan la interacción entre procesos concurrentes.

Métodos basados en Redes de Petri: modelo formal basado en flujos de información. Permiten expresar eventos concurrentes.

Métodos basados en lógica temporal: se usan para especificar sistemas concurrentes y reactivos.

 

• Proporciona un mecanismo para eliminar muchos de los problemas que son difíciles de superar con paradigmas de la ingeniería de software.

• Permite descubrir y corregir errores que no se pudieron detectar de otra forma.

• Ofrecen la promesa de un software libre de defectos.

 

• Es bastante caro y lleva mucho tiempo.

• Pocos desarrolladores de software tienen antecedentes necesarios para aplicar métodos formales.

• Es difícil utilizarlos como un mecanismo de comunicación con clientes.

 

 

GRÁFICOS

 

 

Modelo Lineal Secuencial

 

 


                                                                                             

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 

Modelo de Construcción de Prototipos

Modelo de Desarrollo Rápido de Aplicaciones (DRA)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


Modelo Incremental

 

 


                                                                                                                                   

 

 

Modelo en Espiral

 

 

 

 

Modelo de Ensamblaje de Componentes

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Modelo de Desarrollo Concurrente

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


EL PROCESO UNIFICADO DE DESARROLLO (PUD)

 

 

 

 

 

 

 

 

 

 

 

 

 

El PUD es un proceso de desarrollo de software.

Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software.

El PUD es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de aptitud y diferentes tamaños de proyecto.

El PUD utiliza el Lenguaje Unificado de Modelado (UML) para preparar todos los esquemas de un sistema software. El UML es una parte esencial del PUD.

 

 

 

 

 

Características

 

El PUD tiene tres características:

 

·         Dirigido por Casos de Usos: para construir un sistema con éxito debemos conocer lo que sus futuros usuarios necesitan y desean. Un usuario representa algo o alguien que interactúa con el sistema. Esta interacción en un caso de uso. Los CU representan los requisitos funciones; guían su diseño, implementación y prueba, es decir, guían el proceso de desarrollo.

 

·         Centrado en la arquitectura: el concepto de arquitectura incluye aspectos estáticos y dinámicos del sistema. La arquitectura es una vista del diseño completo. Cada producto tiene una función (CU) y una forma (arquitectura). Los CU deben encajar en la arquitectura y ésta permitir su desarrollo.

 

 

·         Iterativo e incremental: las iteraciones hacen referencia a pasos en el flujo de trabajo; y los incrementos, al crecimiento del producto. La iteración trata de un grupo de CU que juntos amplían la utilidad del producto.

·          

La arquitectura proporciona la estructura sobre la cual guiar las iteraciones, mientras que los CU definen los objetivos y dirigen el trabajo de cada iteración.

 

Fases del PUD

El PUD tiene 4 fases:

·         Fase de inicio: se desarrolla una descripción del producto final a partir de una idea y se presenta el análisis de negocio para el producto.

·         Fase de elaboración: se especifican en detalle la mayoría de los CU y se diseña la arquitectura del sistema.

 

·         Fase de construcción: se crea al producto.

 

·         Fase de transición: se prueba el producto y se informan defectos e deficiencias.

 

Flujos de trabajo del PUD

 

Un FT es un conjunto de actividades, herramientas y estándares que se usan en un proceso. Cada FT está compuesto por:

·         Actividades: son las tareas que se llevan a cabo en el FT.

·         Trabajadores: son quiénes ejecutan las actividades.

·         Artefactos: es toda la información generada a partir del trabajo realizado en el FT.

En el PUD existen cinco FT:

·         FT de Requerimientos.

·         FT de Análisis.

·         FT de Diseño

·         FT de Implementación.

·         FT de Prueba.

 

 

 


UNIDAD Nº 3

“EL PARADIGMA DE LA ORIENTACIÓN A OBJETOS”

 

La complejidad del software

Se debe a:

·         La complejidad del dominio del problema.

·         La dificultad de gestionar el proceso de desarrollo.

·         La flexibilidad que se puede alcanzar a través del software.

·         Los problemas de caracterizar el comportamiento de sistemas discretos.

 

Paradigma

Paradigma es una forma de “ver” y “entender” el mundo, es una forma de abstraerlo dentro de nuestra cabeza.

 

Programación orientada a objetos (POO)

 

La POO es un paradigma de programación que usa objetos y sus interacciones para diseñar aplicaciones y programas de computadora.

Está basado en varias técnicas, incluyendo herencia, modularidad, polimorfismo y encapsulamiento.

Considera al mundo como un conjunto de entidades u objetos que están relacionados y se comunican entre ellos.

 

Elementos del Modelo de Objetos

 

  • Abstracción: denota las características esenciales de un objeto que lo distinguen de todos los demás tipos de objeto y proporciona fronteras conceptuales. Se centra en la visión externa de un objeto.
  • Encapsulamiento: es el proceso de almacenar en un mismo compartimiento los elementos de una abstracción que constituyen su estructura y su comportamiento. Separa la abstracción y su implementación. Se consigue con la ocultación de información.
  • Modularidad: es la propiedad que tiene un sistema que ha sido descompuesto en un conjunto de módulos cohesivos y acoplados.
  • Jerarquía: es una clasificación u ordenación de abstracciones.
  • Herencia: es un mecanismo para expresar similaridad entre clases, simplificando definiciones de las clases similares previamente definidas. La herencia permite crear nuevas clases llamadas subclases agregando solamente las diferencias con la clase. En otras palabras la herencia es una partición en subclases más especializadas.

 

Hay tres elementos secundarios:

  • Tipos (tipificación): un tipo es una caracterización precisa de propiedades estructurales o de comportamiento que comparten una serie de entidades. La tipificación hace posible que objetos de distintos tipos no puedan intercambiarse.
  • Concurrencia: permite a diferentes objetos actuar al mismo tiempo. Permite distinguir un objeto activo de uno que no lo está.
  • Persistencia: conserva el estado de un objeto en el tiempo y en el espacio.

 

OBJETOS

 

Un objeto modela alguna parte de la realidad. Es algo que existe en el tiempo y el espacio.

Es la abstracción de alguna cosa en el dominio del problema que refleja la capacidad de un sistema de alcanzar información alrededor de él.

Un objeto tiene estado, comportamiento e identidad; la estructura y comportamiento de objetos similares están definidos en su clase.

 

Estado

El estado de un objeto abarca todas las propiedades del mismo mas los valores actuales de cada una de esas propiedades.

 

Comportamiento

El comportamiento es cómo actúa y reacciona un objeto, en términos de sus cambios de estado y paso de mensajes.

El comportamiento de un objeto representa su actividad visible exteriormente.

Una operación es una acción que un objeto efectúa sobre otro con el fin de provocar una reacción.

Las responsabilidades de un objeto son todos los servicios que proporciona para todos los “contratos” que soporta.

 

Identidad

La identidad es aquella propiedad de un objeto que lo distingue de todos los además objetos.

 

Relaciones entre objetos

Los objetos contribuyen al comportamiento de un sistema colaborando con otros. Esto se logra a través de las relaciones.

Hay dos tipos de relaciones:

·         Enlace: es una conexión entre objetos. Un objeto colabora con otros a través de sus enlaces.

·         Agregación: la agregación denota una jerarquía todo/parte, con la capacidad de ir desde el todo hasta sus partes.

 

CLASES

Una clase es un conjunto de objetos que comparten una estructura común y un comportamiento común.

Un objeto es una instancia de una clase.

 

Vistas de una clase

Una clase posee dos vistas:

·         Interfaz: proporciona su vista externa. Enfatiza la abstracción y oculta su estructura y comportamiento. Se compone principalmente de las declaraciones de todas las operaciones aplicables a instancias de la clase (objetos).

·         Implementación: es su vista interna. Engloba los secretos de su comportamiento. Se compone de la implementación de todas las operaciones definidas en la interfaz.

 

 

Estructura de una clase

 

 

 

 

 

 

 

 

 

 

 

 

 


·         Nombre: cada clase ha de tener un nombre que la distinga de otras clases.

·         Atributos: características propias de un objeto, correspondientes a una clase.

·         Métodos: Es un algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer.

 

Responsabilidades

Una responsabilidad es un contrato o una obligación de una clase.

 

Mensajes

Los objetos tienen la posibilidad de actuar; la acción sucede cuando un objeto recibe un mensaje, que es, una solicitud que pide al objeto que se comporte de alguna forma.

 

DIAGRAMA DE CLASES

·         CLASIFICACION: de Estructura, Estático, Lógico.

·         USO:

ü  Explorar conceptos del dominio.

ü  Analizar Requerimientos.

ü  Mostrar el diseño detallado del SW Orientado a Objetos.

·         Muestra: un conjunto de clases, interfaces, colaboraciones y sus relaciones.

·         Contiene comúnmente:

ü  Clases

ü  Interfaces (tipo especial de clases)

ü  Relaciones

 

Clases y objetos candidatos

Las clases y objetos candidatos provienen de las siguientes fuentes:

·         Cosas tangibles (producto, herramienta, automóvil)

·         Lugares (Barrio, Provincia, País, Zona)

·         Transacciones o operaciones (Venta, Pago, Pedido)

·         Hechos o eventos (Reserva, Vuelo, Accidente, Incidente)

·         Roles de personas (Proveedor, Cliente, Empleado)

·         Contenedores de otras cosas (Almacén)

·         Catálogos (catalogo de productos)

·         Otras organizaciones u áreas (Ministerio, Juzgado, dpto. de ventas.

Relaciones entre clases

Existen distintos tipos de relaciones:

·         Asociación: denota sólo una dependencia, sin establecer la dirección de esa dependencia.

ü  Navegabilidad: la dirección de la navegación indica qué clase es la que contiene la referencia hacia la otra (determina “quién conoce a quién”).

ü  Multiplicidad: señala cuántos objetos pueden conectarse a través de una instancia de la asociación.

 

·         Agregación: el elemento destino es parte del elemento de origen. Representa una relación entre un “todo” y sus “partes”.

·         Generalización: es una relación en la que una clase comparte la estructura y/o el comportamiento definidos en una (herencia simple) o más clases (herencia múltiple). El elemento origen es una especialización del elemento destino.

 

·         Dependencia: el elemento origen depende del elemento destino y puede verse afectado por los cambios en él.

 

 

 

 

 

 

 

LENGUAJE UNIFICADO DE MODELADO (UML)

 

UML es un lenguaje estándar para escribir planos de software. Es independiente del proceso.

 

Modelo

Un modelo es una simplificación de la realidad. Es una representación a bajo costo de la realidad. Construimos modelos para comprender mejor el sistema que estamos desarrollando.

Un modelo simplifica la complejidad.

 

Objetivos del modelado

·         Los modelos ayudan a visualizar cómo es que queremos que sea un sistema.

·         Los modelos permiten especificar la estructura o el comportamiento de un sistema.

·         Los modelos proporcionan plantillas que sirven de guía en la construcción del software.

·         Los modelos documentan las decisiones que se han adoptado.

 

Visión general de UML

UML es un lenguaje para:

·         Visualizar: detrás de cada símbolo UML hay una semántica bien definida.

·         Especificar: tiene que ver con la construcción de modelos precisos, no ambiguos y completos.

·         Construir: permite generar código a partir de los modelos.

·         Documentar: permite generar una serie de artefactos.

 

Modelo conceptual de UML

UML posee tres elementos principales:

·         Bloques de construcción.

·         Reglas.

·         Mecanismos comunes.

 

Bloques de construcción

UML incluye tres clases de bloques de construcción:

·         Elementos.

·         Relaciones.

·         Diagramas.

Los elemento son abstracciones, las relaciones ligan elementos entre sí, y los diagramas agrupan colecciones de elementos.

 

Elementos

Hay cuatro tipos de elementos en UML:

1.      Elementos estructurales.

2.      Elementos de comportamiento.

3.      Elementos de agrupación.

4.      Elementos de anotación.

 

Elementos estructurales: representan cosas que son conceptuales o materiales. Hay siete tipos de elementos estructurales:

·         Clase: es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase implementa una o más interfaces.

·         Interfaz: es una colección de operaciones que especifican un servicio de una clase o componente. Describe el comportamiento visible externamente de ese elemento.

·         Colaboración: define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor.

·         Caso de uso: es una descripción de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de interés para un actor particular. Un CU es realizado por una colaboración.

·         Clase activa: es una clase cuyos objetos tienen uno o más procesos o hilos de ejecución.

·         Componente: es una parte física y reemplazable de un sistema.

·         Nodo: es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional.

 

Elementos de comportamiento: son las partes dinámicas de los modelos UML. Representan comportamientos en el tiempo y en el espacio. Hay dos tipos de elementos comportamiento:

 

·         Interacción: es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos. Involucra muchos otros elementos (mensajes, secuencias de acción y enlaces).

 

 


·         Máquina de estados: es un comportamiento que especifica las secuencias de estados por las que pasa un objeto o una interacción durante su vida en respuesta a eventos.

 

Elementos de agrupación: son las partes organizativas de los modelos UML. Hay un elemento de agrupación principal:

 

·         Paquete: es un mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales, de comportamiento e incluso otros de agrupación pueden incluirse en un paquete.

También hay variaciones, como los frameworks, los modelos y los subsistemas.

 

Elementos de anotación: son las partes explicativas de los modelos UML. Hay un tipo principal de elemento de anotación:

 

·         Nota: es un símbolo para mostrar restricciones y comentarios junto a un elemento o una colección de elementos.

Relaciones

Hay cuatro tipos de relaciones en UML:

1.      Dependencia.

2.      Asociación.

3.      Generalización.

4.      Realización.

 

Dependencia: es una relación semántica entre dos elementos, en la cuan un cambio a un elemento puede afectar a la semántica del otro.

 

Asociación: es una relación estructural que describe un conjunto de enlaces. La agregación es un tipo especial de asociación, que representa una relación estructural entre un todo y sus partes.

 

Generalización: es una relación de especialización en la cual los objetos de elemento especializado (hijo) pueden sustituir a los objetos del elemento general (padre).

 

Realización: es una relación semántica entre clasificadores, en donde un clasificador especifica un contrato que otro clasificador garantiza que cumplirá.

 

Diagramas

Un diagrama es la representación gráfica de un conjunto de elementos. Se dibujan para visualizar un sistema desde diferentes perspectivas.

 

Diagrama de clases: muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Cubre la vista estática de un sistema.

Diagrama de objetos: muestra un conjunto de objetos y sus relaciones. Representan instantáneas de instancias de los elementos encontrados en los diagrama de clases. Cubren la vista estática de un sistema.

 

Diagrama de CU: muestra un conjunto de CU y actores (tipo especial de clases) y sus relaciones. Cubre la vista estática de un sistema.

 

Diagrama de interacción: muestra una interacción, que consta de un conjunto de objetos y sus relaciones, incluyendo los mensajes que pueden ser enviados entre ellos. Cubre la vista dinámica de un sistema. Hay dos tipos:

 

·         Diagrama de secuencia: es un diagrama de interacción que resalta la ordenación temporal de los mensajes.

·         Diagrama de colaboración: es un diagrama de interacción que resalta la organización estructural de los objetos que envían y reciben mensajes.

 

Diagrama de estados: muestra una máquina de estados. Cubre la vista dinámica de un sistema.

 

Diagrama de actividades: es un tipo especial de diagrama de estados que muestra el fuljo de actividades dentro de un sistema. Cubre la vista dinámica de un sistema.

 

Diagrama de componentes: muestra la organización y las dependencias entre un conjunto de componentes. Cubre la vista estática de un sistema.

 

Diagrama de despliegue: muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. Cubre la vista estática de un sistema.

 

Reglas

 

UML tiene reglas semánticas para:

·         Nombres: cómo llamar a los elementos, relaciones y diagramas.

·         Alcance: el contexto que da un significado específico a un nombre.

·         Visibilidad: cómo se pueden ver y utilizar esos nombres por otros.

·         Integridad: cómo se relacionan apropiada y consistentemente unos elementos con otros.

·         Ejecución: qué significa ejecutar o simular un modelo dinámico.

 

Es común en el equipo de desarrollo construir modelos no sólo bien formados, sino también:

  • Abreviados: ciertos elementos se ocultan para simplificar la vista.
  • Incompletos: pueden estar ausentes ciertos elementos.
  • Inconsistentes: no se garantiza la integridad del modelo.

 

Mecanismos comunes

 

UML se simplifica con la presencia de cuatro mecanismos comunes:

  • Especificaciones: proporcionan una base semántica que incluye a todos los elementos de todos los modelos de un sistema.
  • Adornos
  • Divisiones comunes: al modelar sistemas orientados a objetos las cosas pueden dividirse al menos en un par de formas.
  • Mecanismos de extensibilidad: Estereotipos, Valores etiquetados, Restricciones.


UNIDAD Nº 4

“EL MODELADO DE NEGOCIO”

 

PROPÓSITOS DEL MODELADO DE NEGOCIO

Los propósitos del modelado de negocio son:

·         Entender la estructura y dinámicas de la organización en la cual se desarrollará el sistema.

·         Comprender los problemas reales en la organización e identificar potenciales mejoras.

·         Asegurar que los clientes, usuarios finales y desarrolladores tengan un entendimiento común de la organización.

·         Derivar los requerimientos para los sistemas que soportarán la organización.

 

TRABAJADORES DEL MODELADO DE NEGOCIO

Los principales trabajadores que están involucrados en el modelado de negocio son los siguientes:

·         Analista de Proceso de Negocio: conduce y coordina el modelado de CU.

·         Diseñador de Negocio: detalla la especificación de una parte de la organización describiendo uno o varios CU.

 

NOTACIÓN DEL MODELADO DE NEGOCIO

La notación del modelado de negocio puede resumirse de la siguiente forma:

  • Usuarios de Negocio (clientes, proveedores, socios) son representados como ACTORES DE NEGOCIO (AN).

  • Los procesos de negocio son representados por CU DE NEGOCIO y REALIZACIONES DE CU.

  • Los roles que juegan las personas en una organización son representados por TRABAJADORES DE NEGOCIO (TN).

  • Las “cosas” que una organización administra o produce son representadas por ENTIDADES DE NEGOCIO (EN).

MODELO DE CU DE NEGOCIO

 

Un modelo de CU de negocio describe procesos de un negocio y sus interacciones con el exterior, clientes, socios.

El propósito principal del modelo de CU de negocio es describir como es usado el negocio por sus clientes y socios.

 

Características de un buen Modelo de CU de Negocio

  • Los CU concuerdan con el negocio que ellos describen.
  • Se han detectado todos los CU.
  • Cada actividad del negocio debería incluirse en al menos un CU.
  • Debería haber un equilibrio entre el número de CU y el tamaño de los CU.
  • Cada CU debe ser único.
  • La revisión del modelo e CU debería dar una vista comprensiva de la organización.

 

CU de Negocio

Una instancia de CU de negocio es una secuencia de acciones que realiza un negocio para producir un resultado observable de valor para un actor individual del negocio.

 

Categorías de CU de Negocio

Existen tres categorías de CU de negocio:

  • CU esenciales: actividades comercialmente importantes (procesos de negocio).
  • CU de soporte. Actividades que no son comercialmente importantes, pero que deben realizarse para hacer el trabajo del negocio.
  • CU de administración: representan trabajo que afecta cómo otros procesos son administrados y las relaciones de negocio con sus dueños (actividades de Gerencia General).

 

Vistas del negocio

En un proyecto conducido por CU se pueden desarrollar dos vistas del negocio:

·         CU de negocio: el CU de negocio en sí mismo presenta una vista externa del negocio, la cual define qué es esencial que el negocio realice para entregar el resultado deseado al actor.

 

·         Realización del CU de negocio: da una vista interna del CU de negocio, la cual define cómo debería ser organizado y ejecutado el trabajo para alcanzar los mismos resultados deseados.

Ambas vistas están desarrolladas para las personas que están relacionadas con el negocio; la vista externa, para la gente que trabaja fuera del CU de negocio, y la vista interna, para las personas que trabajan dentro del CU de negocio.

 

Nombre de un CU

El nombre del CU de negocio debería expresar qué pasa cuando una instancia del CU es ejecutada.

Actor

Un actor de negocio representa un rol jugado en relación al negocio, por algo o alguien en el entorno del negocio.

Varios usuarios físicos pueden jugar el mismo rol; y un mismo usuario puede actuar como varios actores diferentes.

 

Nombre de un actor

Un AN debería tener un nombre que refleje su rol con relación al negocio.

 

Características de un AN

 

·         Todos los actores son encontrados.

·         Cada actor humano representa un rol.

·         Cada actor modela algo fuera del negocio.

·         Cara actor está involucrado al menos con un CU.

·         Un actor específico no interactúa con el negocio de varias formas diferentes.

·         Cada actor tiene un nombre explicatorio y una descripción.

 

Generalización de Actores

 

Una generalización de actor, de una clase actor (hijo) a otra clase de actor (padre) indica que el “hijo” hereda el rol que el “padre” puede jugar en un CU.

 

Diagrama de CU en el Modelo de CU de Negocio

Un diagrama de CU muestra actores, CU de negocio, paquetes de CU y sus relaciones.

 

Asociaciones de comunicación

Una asociación de comunicación entre un CU y un actor indica que una instancia de un CU y una instancia del actor van a interactuar.

 

Estructurando el Modelo de CU de Negocio

 

Hay tres razones para estructurar el modelo de CU de negocio:

·         Para hacer los CU más fáciles de entender.

·         Para reusar partes de WF que son compartidas entre varios CU de negocio.

·         Para hacer el modelo de CU de negocio más fácil de mantener.

 

Para estructurar CU se tienen tres clases de relaciones:

·         Extensión.

·         Inclusión.

·         Generalización.

 

Relación de Extensión

Una relación de extensión es una relación desde un CU de extensión a un CU base, especificando como el comportamiento definido en el CU de extensión puede ser insertado en el comportamiento definido por el CU base.

La relación de extensión agrega un flujo al CU de negocio que es completo en sí mismo. Su usa para modelar un comportamiento opcional.

Como la ejecución del CU es opcional, al ejecutarse el CU base, el CU de extensión sólo se ejecutará bajo ciertas condiciones.

Relación de Inclusión

Una relación de inclusión es una relación desde un CU base a un CU de inclusión, especificando como el comportamiento definido en el CU de inclusión es explícitamente insertado en el comportamiento definido en el CU base.

La relación no es opcional; por ello, al ejecutarse el CU base, siempre se ejecutará el CU de inclusión.

Se usa cuando el comportamiento del CU de inclusión puede ser reusado por otros CU, o cuando un CU es muy complejo se divide para simplificar su funcionalidad.

 

Relación de Generalización

 

Una generalización de CU es una relación desde un CU hijo a un CU padre, especificando como el hijo puede especializar todo el comportamiento y características descriptas por el padre.

 

CU de negocio Concreto y Abstracto

 

·         CU de negocio Concreto: es aquel CU que es instanciado por sí solo, por iniciativa de un AN o de un TN.

·         CU de negocio Abstracto: es aquel CU que no es instanciado por sí solo, si no que es instanciado por otro CU (por inclusión o extensión).

 

MODELO DE OBJETOS DE NEGOCIO

 

Es un modelo que describe la realización de CU de negocio. Sirve como una abstracción de cómo necesitan relacionarse los TN y las EN y cómo necesitan colaborar para ejecutar el negocio. Describe un CU de negocio desde un punto de vista interno.

 

Realización de CU de Negocio

Una realización de un CU de negocio describe cómo un CU de negocio particular es realizado con los modelos de objetos de negocio, en términos de objetos colaborando.

 

Entidad de Negocio

Una EN representa una “cosa” manejada o usada por TN cuando ejecutan un CU de negocio.

Comúnmente un EN representa un documento o una parte esencial de un producto o algo menos tangible como el conocimiento o información acerca de un cliente, proveedor, etc.

 

 

 

 

 

 

 

 

 

 

 

Trabajador de Negocio

 

Un TN representa un rol o conjunto de roles de negocio. Un TN interactúa con otros trabajadores y manipula EN mientras participa en las realizaciones de CU de negocio.

Un TN representa una abstracción de un humano que actúa dentro del negocio, o una abstracción del SI que llamamos trabajador automatizado, cuando el actor en vez de comunicarse con un TN humano accede directamente al sistema.

 

 

Diagramas de Colaboración y de Secuencia

 

Para cada realización de CU de negocio puede haber uno o más diagramas de interacción que representan los TN, las EN y sus interacciones. Hay dos tipos de diagrama de interacción:

·         Diagrama de secuencia.

·         Diagrama de colaboración.

 

Diagrama de Colaboración en el Modelo de Objetos de Negocio

 

Un diagrama de colaboración describe un patrón de interacciones entre objetos, muestra los objetos participantes en la interacción, por sus conexiones entre sí y los mensajes que se envían entre ellos.

Muestra los TN que deben interactuar y que EN deben utilizarse para ejecutar el WF en un CU de negocio. También puede mostrar los actores.

Existen dos tipos:

·         De equipo: se excluyen los mensajes y la secuencia de los mismos.

·         De trabajo: incluye mensajes y secuencia.

 

 


UNIDAD Nº 5

“INGENIERÍA DE REQUERIMIENTOS”

 

REQUERIMIENTOS

 

Es difícil establecer exactamente lo que el sistema debe hacer. Las descripciones de los servicios y restricciones son los requerimientos para el sistema, y el proceso de descubrir, analizar, documentar y verificar estos servicios y restricciones se llama ingeniería de requerimientos.

 

·         Requerimientos del usuario: servicios que se espera que el sistema provea y restricciones bajo las cuales debe operar.

·         Requerimientos del sistema: servicios y restricciones del sistema.

·         Especificación del diseño del software: descripción abstracta del diseño del software que es una base para un diseño e implementación detallados. Agrega detalles a la especificación de requerimientos del sistema (ERS).

 

Requerimientos funcionales

Describen la funcionalidad o los servicios que se espera que el sistema provea. Éstos dependen del tipo de software y del sistema que se desarrolle y de los posibles usuarios del software.

 

 

Requerimientos no funcionales

Son aquellos que no se refieren a las funciones específicas del sistema, sino a las propiedades de éste (fiabilidad, respuesta en el tiempo, capacidad de almacenamiento, etc.).

Definen restricciones del sistema como capacidad de los dispositivos de E/S y la representación de los datos que se utilizan en las interfaces del sistema.

A menudo son más críticos que los RF, ya que el incumplimiento de este último degradará al sistema, mientras que una falla en un RNF lo inutiliza.

Los RNF surgen de las necesidades del usuario, debido a restricciones en el presupuesto, a las políticas de la organización, etc.

·         Del producto.

ü   Eficiencia.

ü   Usabilidad

ü   Performance.

ü   Fiabilidad.

ü   Estabilidad

ü   Etc.

·         Organizacionales.

ü   Estándares de proceso.

ü   Lenguaje de programación.

ü   Requerimientos de implementación.

·         Externos.

ü   Legales.

ü   Éticos.

ü   Impositivos.

 

Requerimientos del dominio

 

Éstos se derivan del sistema más que de las necesidades específicas de los usuarios. Pueden ser RNF, RF nuevos, restringir los existentes o establecer cómo se deben ejecutar cálculos particulares.

 

Requerimientos del usuario

 

Especifican el comportamiento externo del sistema y evitan las características de diseño del sistema.

Los requerimientos del usuario deben simplemente enfocarse a los recursos principales a proveer.

 

Requerimientos del sistema

 

Éstos son descripciones más detalladas de los requerimientos del usuario. Sirven como base para definir el contrato de la especificación del sistema y, por lo tanto, debe ser una especificación completa y consistente del sistema.

Los requerimientos del sistema deben establecer lo que éste hará y no la manera en que se implementará.

 

Verdaderos Requerimientos

 

Son aquellos que pueden ser solucionados a partir del desarrollo de  un sistema de información. Tienen que ver con el dominio del problema.

El proceso de determinación de requerimientos para un sistema basado en computadoras implica en primer lugar trabajar con los clientes para extraer los requerimientos, formulando preguntas, haciendo demostraciones del sistemas similares y hasta desarrollando prototipos de todo o parte del sistema propuesto. Después se capturan dichos requerimientos en un documento o una base de datos, para ello se escriben los requerimientos, de modo que los clientes y los desarrolladores  puedan ponerse de acuerdo  acerca de lo que el sistema debe hacer.

 

Categorías de Requerimientos

 

·         Requerimientos que  deben ser absolutamente satisfechos.

·         Requerimientos que son deseables pero no indispensables.

·         Requerimientos que son posibles, pero que podrían eliminarse.

 

Características de los Requerimientos

 

·         Correctos.

·         Consistentes.

·         Completos.

·         Realistas.

·         Necesarios.

·         Verificables.

·         Rastreables.

 

 

DOCUMENTO DE REQUERIMIENTOS DEL SOFTWARE Ó ESPECIFICACIÓN DE REQUERIMIENTOS DEL SOFTWARE (ERS)

 

Es la declaración oficial de qué es lo que requieren los desarrolladores del sistema. Incluye tanto los requerimientos del usuario para el sistema como una especificación detallada de los requerimientos del sistema.

 

Los requisitos que debe satisfacer la ERS son:

·         Especificar únicamente el comportamiento externo del sistema.

·         Especificar las restricciones de la implementación.

·         Ser fácil de cambiar.

·         Servir como herramienta de referencia para los mantenedores del sistema.

·         Registrar las previsiones del ciclo de vida del sistema.

·         Caracterizar las respuestas aceptables para los eventos no deseados.

 

 

Estructura y contenido de la ERS

 

·         Introducción

ü  Propósito del documento: delinear el propósito de la ERS y especificar a quién se dirige.

ü  Definiciones, acrónimos y abreviaturas: incluir las definiciones de los términos, acrónimos y abreviaturas requeridas para interpretar la ERS.

ü  Audiencia: indicar a quiénes va dirigido el documento y cuál será su utilidad.

ü  Alcance: identificar los productos de SW, explicar que hará y que no hará cada uno, escribir la aplicación.

ü  Referencias: proveer una lista completa de todos los documentos referenciados.

·         Presentación del Producto

ü Propósito del Sistema

ü  Restricciones y Supuestos: límites a las opciones para diseñar el sistema. Restricciones económicas, legales, impositivas, etc.

·         Descripción General

ü  Listado de la Funcionalidad del Sistema: resumen de las funciones que ejecutará el SW.

ü  Listado de Actores: características generales de los usuarios (descripción de los actores).

ü  Perspectiva del Producto: relación con otros productos o proyectos, productos independientes, componentes de un sistema o de un proyecto, HW y equipamiento periférico, restricciones de diseño.

·         Descripción Detallada de Requerimientos

ü  Requerimientos Funcionales: diagrama de CU del SI y descripción de CU.

ü  Requerimientos No Funcionales: plantilla de descripción de RNF.

o   Del Producto

o   Del Ambiente

·         Requerimientos de Interfaz

ü  Interfaces de Usuario

ü  Interfaces de Hardware

ü  Interfaces de Software

ü  Interfaces de Comunicación

·         Restricciones de Diseño

·         Operaciones

·         Requerimientos de Licencia

·         Componentes Comprados

·         Observaciones

 

PROCESO DE INGENIERÍA DE REQUERIMIENTOS (PIR)

 

La ingeniería de requerimientos es un proceso que comprende todas las actividades requeridas para crear y mantener un documento de requerimientos del sistema (ERS). Es un proceso iterativo que incluye las siguientes actividades:

·         Estudio de factibilidad.

·         Elicitación de requerimientos.

·         Especificación de requerimientos.

·         Validación de requerimientos.

 

Estudio de factibilidad

 

La entrada es una descripción del sistema y de cómo se utilizará en la organización. El resultado es un informe que recomienda si es conveniente llevar a cabo la ingeniería de requerimientos y el proceso de desarrollo del sistema.

 

Elicitación de requerimientos

 

En esta actividad se trabaja con los clientes y los usuarios finales del sistema para determinar el dominio de la aplicación, cuáles servicios  debe proveer el sistema, el desempeño requerido por el sistema, las restricciones de hardware, etc.

La elicitación incluye diferentes tipos de personas de la organización. El término stakeholders se utiliza para referirse a cualquier persona que tiene influencia directa o indirecta sobre los requerimientos del sistema.

Las actividades del proceso son:

·         Comprensión del dominio.

·         Recolección de requerimientos.

·         Clasificación.

·         Resolución de conflictos.

·         Priorización.

·         Verificación de requerimientos.

·          

Especificación de requerimientos

 

La tarea fundamental que se define para este proceso es la de realizar una análisis de los requerimientos detectados y la creación de los modelos necesarios que representen la solución del software, que tiene en cuenta esos requerimientos.

La solución presentada es una solución lógica o teórica, libre de cualquier aspecto referido a como se implementará el sistema. 

Como resultado de desarrollo de este proceso se obtiene el documento de Especificación de Requerimientos de Software (ERS) que expresa los requerimientos funcionales detectados a través de los modelos que dan solución a los mismos.

Algunas de las principales herramientas que nos permiten realizar la especificación de requerimientos funcionales y realizar la ERS son:   

·         Diagrama de Casos de Uso.

·         Descripción de Casos de Uso.

·         Diagrama de Clases.

 

Validación de requerimientos

 

La validación muestra que los requerimientos son los que definen el sistema que el cliente desea.

Es importante debido a que los errores en la ERS pueden conducir a costos excesivos.

Se deben llevar a cabo diferentes tipos de verificación:

·         Verificación de validez.

·         Verificación de consistencia: los requerimientos no deben contradecirse.

·         Verificación de integridad: los requerimientos deben cubrir todas las funciones y restricciones propuestas por el usuario.

·         Verificación de realismo: los requerimientos deben verificarse para asegurar que se puedan implementar.

·         Verificabilidad.

 

ADMINISTRACIÓN DE REQUERIMIENTOS

 

Los requerimientos para sistemas de software grandes son siempre cambiantes. Debido a que el problema no puede definirse completamente, los requerimientos de software son incompletos. Durante el proceso del software, la comprensión del problema por el desarrollador está cambiando constantemente y estos cambios retroalimentan a los requerimientos.

La administración de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos del sistema.

 

Requerimientos duraderos y volátiles

 

Desde una perspectiva evolutiva, los requerimientos son de dos clases:

·         Requerimientos duraderos: son relativamente estables que se derivan de la actividad principal de la organización y están directamente relacionados con el dominio del problema.

 

·         Requerimientos volátiles: cambian durante el desarrollo del sistema o después de que éste se haya puesto en operación.


UNIDAD Nº 6

“EL PROCESO DE ELICITACIÓN DE REQUERIMIENTOS”

 

La elicitación es el proceso de obtención y análisis de los requerimientos.

Las principales herramientas son las siguientes:

·         Entrevista.

·         Cuestionario.

·         Observación.

·         Investigación.

·         Muestreo.

·         Otras.

 


TÉCNICA /
HERRAMIENTA

DESCRIPCIÓN

VENTAJAS

DESVENTAJAS

NIVEL DE LA
ORGANIZACIÓN

ANÁLISIS DE

DATOS

TIPO DE INF. RELEVADA

FUENTE DE INFORMACIÓN

ENTREVISTA

Es una conversación dirigida con un propósito específico que utiliza un formato de preguntas y respuestas.

-Se pueden descubrir sentimientos de los entrevistados, y por lo tanto, la cultura de la organización.

-Se pueden descubrir rápidamente malos entendidos, falsas expectativas o resistencia potencial para las aplicaciones en desarrollo.

-En el caso de la Gerencia, es más fácil calendarizar una entrevista que pedirles que llenen cuestionarios.

 

-Requieren mucho tiempo.

-Está sujeta a errores.

-Los datos obtenidos están propensos a una mala interpretación.

Todos los niveles.

-Se debe captar la esencia de la entrevista a través de un informe escrito, el cual debe ser realizado lo más pronto posible, para asegurar la calidad de los datos.

-Se deben registrar os puntos principales y las opiniones propias. Es importante repasar el informe con el entrevistado.

-Información cualitativa: opiniones y parecer acerca del sistema, metas organizacionales y personales y procedimientos informales.

-Personas

TÉCNICA /
HERRAMIENTA

DESCRIPCIÓN

VENTAJAS

DESVENTAJAS

NIVEL DE LA
ORGANIZACIÓN

ANÁLISIS DE

DATOS

TIPO DE INF. RELEVADA

FUENTE DE INFORMACIÓN

DISEÑO CONJUNTO DE APLICACIO-NES (JAD)

Desarrollada por IBM como un método alternativo para entrevistar usuarios uno a uno.

Tiene un carácter interactivo y tiene mucho en común con las técnicas de “lluvia de ideas”.

-Reducción del tiempo y el costo.

-Mejor calidad de resultados de la evaluación de los requeri-mientos.

-Ayuda a los usuarios a involucrarse en las etapas de los proyectos de sistemas.

-Desarrollo de diseños creativos.

-Requiere que los participantes dediquen mucho tiempo.

-El éxito de las sesiones JAD es menos predecible.

-No puede ser aplicado en cualquier organización.

Todos los niveles (preferentemente, por encima del Nivel Operativo).

-Se debe preparar un documento de especifi-caciones técnicas con base a lo que haya ocurrido en la reunión.

-Se deben presentar los objetivos de los directivos, y los límites y alcances del proyecto.

-Información cualitativa.

-Personas


TÉCNICA /
HERRAMIENTA

DESCRIPCIÓN

VENTAJAS

DESVENTAJAS

NIVEL DE LA
ORGANIZACIÓN

ANÁLISIS DE

DATOS

TIPO DE INF. RELEVADA

FUENTE DE INFORMACIÓN

CUESTIONARIO

Es una técnica que permite estudiar las actitudes, creencias, comportamiento y características de muchas personas en la organización.

Puede ser usado para encuestar una muestra considerable de usuarios con el fin de detectar problemas o poner de manifiesto cuestiones importantes antes de que se realicen las entrevistas.

-Permite relevar información de un gran número de personas en poco tiempo.

-Las preguntas estandarizadas proporcionan datos más confiables.

-No es posible observar expresiones o relaciones.

-Puede necesitarse un seguimiento del cuestionario para motivar al personal que lo responda.

-El desarrollo y distribución de los cuestionarios es costoso y lleva tiempo.

Todos los niveles.

 

-Información cualitativa: la cual puede ser cuantificada si es sometida a escalas (nominales o de intervalos).

-Personas


TÉCNICA /
HERRAMIENTA

DESCRIPCIÓN

VENTAJAS

DESVENTAJAS

NIVEL DE LA
ORGANIZACIÓN

ANÁLISIS DE

DATOS

TIPO DE INF. RELEVADA

FUENTE DE INFORMACIÓN

MUESTREO

Es un proceso que consiste en seleccionar sistemáticamente elementos representativos de una población.

-Es un método económico.

-La recopilación de datos y obtención de resultados es rápida.

-Una muestra ofrece mejor calidad y precisión de los datos.

-Reduce la parcialidad.

-Es posible seleccionar una muestra inadecuada.

 

Todos los niveles.

 

Información referida a problemas que no se pueden medir o implican una gran cantidad de trabajo detallado.

-Personas

INVESTIGA-CIÓN

Es la acción de descubrir y analizar los datos.

Los datos examinados pueden cuantitativos o cualitativos.

-Permite conocer a la organización en su esencia.

 

-Es un proceso bastante esforzado.

-La recopilación de datos es lenta.

Todos los niveles.

 

-Información cuantitativa: referida a toma de decisiones, de desempeño, actualizaciones de lo que ocurre en el negocio, etc.

-Información cualitativa: claves orientadoras, quién envía y recibe documentos.

-Informes

-Registros

-Formularios

-Memorandos

-Carteles o pancartas

-Sitios Web corporativos

-Manuales


TÉCNICA /
HERRAMIENTA

DESCRIPCIÓN

VENTAJAS

DESVENTAJAS

NIVEL DE LA
ORGANIZACIÓN

ANÁLISIS DE

DATOS

TIPO DE INF. RELEVADA

FUENTE DE INFORMACIÓN

OBSERVACIÓN DEL COMPORTA-MIENTO DEL TOMADOR DE DECISIONES

Consiste en identificar con exactitud lo que un gerente hace.

Permite ver personalmente la manera en que un gerente recopila, procesa, comparte y usa la información para realizar su trabajo.

-Permite conocer el procesamiento de la información rápidamente al ver las operaciones personalmente.

-Observando se pueden obtener datos que no se podrían obtener de otra forma.

-La recopilación de datos es lenta y minuciosa.

Nivel Gerencial.

 

-Información referida a la toma de decisiones: manejo de documentos, generación de información, uso de información, relación con los demás miembros de la organización, etc.

-Personas

OBSERVACIÓN DEL ENTORNO FÍSICO

Consiste en examinar sistemáticamente las oficinas de los tomadores de decisiones. Esto pone de manifiesto muchos de sus requerimientos de información.

-Permite reconocer los elementos que se usan en el procesamiento de la información.

-Observando se pueden obtener datos que no se podrían obtener de otra forma.

-La recopilación de datos es lenta y minuciosa.

Nivel Gerencial.

 

-Información referida a la forma en que el tomador de decisiones recopila, procesa almacena y comparte la información.

-Entorno físico (oficinas)


UNIDAD Nº 7

“EL PROCESO DE ESPECIFICACIÓN DE REQUERIMIENTOS”

 

 

Los requerimientos del usuario deben redactarse en lenguaje natural para que sean comprendidos por personas que no son técnicos expertos. Sin embargo, los requerimientos del sistema más detallados se expresan en una forma más técnica. Una técnica muy utilizada es documentar la especificación del sistema como un conjunto de modelos. Estos modelos son representaciones gráficas que describen el problema a resolver y el sistema a desarrollar. Son un puente importante entre los procesos de análisis y diseño.

 

MODELOS

 

El aspecto más importante de un modelo del sistema es que omite los detalles. Es una abstracción del sistema que se está estudiando más que una representación alternativa. Una representación debe mantener toda la información de la entidad, mientras que una abstracción simplifica y selecciona las características más sobresalientes.

Los diferentes tipos de modelos del sistema se basan en varios enfoques de abstracción.

Existen diferentes tipos de modelos del sistema:

·         Modelo de procesamientos de datos: muestra cómo se procesan los datos.

·         Modelo de composición: muestra la manera en que las entidades del sistema se componen de otras entidades.

·         Modelo arquitectónico: muestra los subsistemas principales que componen el sistema.

·         Modelo de clasificación: muestra la manera en que las entidades tienen características comunes.

·         Modelo estímulo-respuesta: muestra la manera en que el sistema reacciona a los eventos.

 

 

 

Modelos de contexto

 

En una de las primeras etapas de la obtención de requerimientos y del proceso de análisis se deben definir los límites del sistema. Esto comprende trabajar con los stakeholders del sistema para distinguir lo que es el sistema y su entorno.

La definición de un contexto del sistema no es una decisión arbitraria.

Una vez que se han decidido los límites del sistema, una parte de la actividad de análisis es la definición de ese contexto y las dependencias que un sistema tiene con su entorno.

 

Modelos de comportamiento

 

Éstos se utilizan para describir el comportamiento del sistema. Existen dos tipos de modelos de comportamiento:

·         Modelos de flujo de datos: son una forma de mostrar la manera en que un sistema procesa los datos. Se utilizan para mostrar cómo fluyen los datos a través de una secuencia de pasos de procesamiento.

·         Modelos de máquinas de estado: se utilizan para modelar el comportamiento de un sistema en respuesta a eventos. Muestra los estados del sistema y los eventos que provocan las transiciones de un estado a otro.

 

Modelos de datos

 

Muchos de los sistemas de software grandes utilizan bases de datos de información de gran tamaño.

La técnica de modelado de datos más utilizada es la de entidad-relación-atributo (modelado ERA).

A menudo, los modelos de datos se utilizan en conjunto con los de fuljo de datos para describir la estructura de la información que se está procesando.

 

Modelos de objetos

 

Se utilizan para representar los datos del sistema y su procesamiento.

Simplifican la transición al diseño y programación orientados a objetos.

CASOS DE USO

 

Los CU se emplean para capturar el comportamiento deseado del sistema en desarrollo. Proporcionan un medio para que los desarrolladores, los usuarios finales del sistema y los expertos del dominio lleguen a una comprensión común del sistema.

Los CU son realizados por colaboraciones, cuyos elementos cooperan para llevar a cabo cada CU.

Nunca deben ser excesivamente genéricos ni demasiado específicos.

 

Casos de Uso: definición

 

Un CU es una descripción de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor.

Representa cada forma en que los actores usan el sistema. Los casos de uso son fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores.

Es una “especificación”. Especifica el comportamiento de “cosas” dinámicas, en este caso instancias de CU. Una instancia de un CU es la realización (o ejecución) de un CU del sistema de información.

 

Los CU:

·         Son descripciones de la funcionalidad del sistema independientes de la implementación.

·         Describen los límites del sistema y las relaciones entre el sistema y el entorno.

·         Definen el conjunto de requerimientos, atendiendo a la categoría de usuarios que participan en el mismo.

·         Particionan en forma de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del usuario (el usuario debería poder entenderlos para realizar su validación).

 

 

 

Tipos de CU

 

Los CU pueden ser:

·         Esenciales: describen una funcionalidad principal o esencial con la que tiene que cumplir el sistema. Comprenden los principales procesos que debe ejecutar el SI.

·         De soporte: comprenden la funcionalidad que surge a partir de analizar aquello que se necesita para que pueden funcionar los CU esenciales.

 

 

CU y actores

 

Un actor representa un conjunto coherente de roles que los usuarios de los CU juegan al interactuar con éstos. Una instancia de un actor representa una interacción individual con el sistema de una forma específica. Aunque se usan actores en los modelos, éstos no forman parte del sistema; son externo a él.

Los actores sólo se pueden conectar a los CU a través de asociaciones.

 

Generalización entre actores

Pueden definirse categorías generales de actores y especializarlos a través de relaciones de generalización. Los actores especializados (hijos) heredan el comportamiento del actor padre.

Si un CU es instanciado por el actor “padre” puede ser instanciado por cualquiera de sus hijos. Ahora bien podría haber CU que son instanciados por uno de los actores “hijo” en particular.

                                   

 

CU y flujo de eventos

 

Un CU describe qué hace un sistema, pero no especifica cómo lo hace.

El comportamiento de un CU se puede especificar describiendo un flujo de eventos de forma textual.

 

CU y escenarios

 

Conviene separar el flujo principal de los flujos alternativos.

Para CU puede haber:

 

·         Escenarios principales: definen secuencias esenciales.

·         Escenarios secundarios: definen secuencias alternativas.

 

 

CU y colaboraciones

 

Un CU debe implementarse y esto se hace creando una sociedad de clases y otros elementos que colaborarán para llevar a cabo el comportamiento del CU.

 

Organización de CU

 

Los CU pueden organizarse agrupándolos en paquetes, de la misma manera que se organizan las clases.

Los CU también pueden organizarse especificando relaciones entre ellos:

 

·         Generalización: el CU hijo hereda el comportamiento del CU padre. El hijo puede modificar y/o agregar comportamiento al CU heredado.

                            

·         Inclusión: el CU base incorpora explícitamente el comportamiento de otro CU en el lugar especificado. El CU incluido sólo es instanciado como parte de algún CU base más amplio que lo incluye.

                  

·         Extensión: el CU base incorpora implícitamente el comportamiento de otro CU en el lugar especificado. El CU puede estar aislado, pero bajos ciertas condiciones su comportamiento puede extenderse con el comportamiento de otro CU.

                          

 

 

 

 

 

DIAGRAMA DE CASOS DE USO

 

Los diagramas de CU se emplean para modelar la vista de CU de un sistema. Esto implica modelar el contexto del sistema, o el modelado de los requisitos de comportamiento de esos elementos.

Los diagramas de CU son importantes para visualizar, especificar y documentar el comportamiento de un elemento.

 

Diagrama de CU: definición

 

Un diagrama de CU es un diagrama que muestra un conjunto de CU, actores y sus relaciones.

Un diagrama de CU contiene:

·         Casos de uso.

·         Actores.

·         Relaciones de dependencia, generalización y asociación.

 

Usos comunes

 

Los diagramas de CU se emplean para modelar la vista de CU estática de un sistema.

Cuando se modela la vista de CU estática de un sistema, normalmente se emplearán los diagramas de CU de una de las dos formas siguientes:

·         Para modelar el contexto de un sistema.

·         Para modelar los requisitos de un sistema.

El modelado de los requisitos de un sistema implica especificar qué debería hacer el sistema, independientemente de cómo se haga.

 

 

Especificación de CU

 

Consiste en describir para cada CU identificado, la secuencia de acciones que se llevan a cabo para cumplir con el objetivo del mismo.

La descripción puede ser:

·         Trazo grueso: describe en forma narrada y general, las acciones principales que son realizadas en un CU.

·         Trazo fino: describe en forma detallada la secuencia de acciones que se llevan a cabo, definiendo el curso normal que se llevaría a cabo en el CU, y las respectivas alternativas al curso normal. En la descripción se deben detallar las acciones a realizar por el actor haciendo uso del sistema.

 

Pre-condiciones

Una pre-condición es una restricción sobre cuándo un CU puede empezar. No es el evento que inicia el CU.

 

Post-condiciones

Una post-condición para un CU debe ser verdadera, independientemente de cual flujo sea ejecutado.


UNIDAD Nº 8

“EL PROCESO DE VALIDACIÓN DE REQUERIMIENTOS”

 

La validación de requerimientos es el proceso mediante el cual se verifican los mismos.

Existen varias técnicas de validación de requerimientos:

·         Revisiones de requerimientos.

·         Construcción de prototipos.

·         Generación de casos de prueba.

·         Análisis de consistencia automático.

 

 

PROTOTIPOS

 

Un prototipo es una versión inicial del sistema de software que se utiliza para demostrar los conceptos, probar las opciones de diseño y, de forma general, enterarse más acerca del problema y sus posibles soluciones.

Un prototipo de software apoya a dos actividades del PIR:

·         Obtención de requerimientos: pueden proponer nuevos requerimientos del sistema.

·         Validación de requerimientos: puede relevar errores y omisiones en los requerimientos propuestos.

 

La construcción de prototipos puede utilizarse como un análisis de riesgo y una técnica de reducción. Un riesgo importante en el desarrollo de software son los errores y omisiones de requerimientos.

El desarrollo de un prototipo del sistema tiene otras ventajas:

·         Se identifican las discrepancias entre los desarrolladores del software y los usuarios.

·         El personal del desarrollo de software puede darse cuenta de que los requerimientos son inconsistentes y/o están incompletos.

·         Se dispone rápidamente de un sistema que funciona y demuestra la factibilidad y usabilidad de la aplicación a administrar.

El desarrollo de un prototipo conduce a mejorar la especificación del sistema. También se utiliza para otros propósitos:

·         Capacitar al usuario.

·         Probar el sistema.

 

 

Prototipos evolutivos y desechables

 

La construcción de prototipos evolutivos inicia con un sistema relativamente simple que implementa los requerimientos más importantes del usuario. Dicho prototipo se aumenta o cambia en cuanto se descubren nuevos requerimientos.

En contraste, el enfoque de construcción de prototipos desechables es para ayudar a refinar y clasificar la especificación del sistema. El prototipo se escribe, evalúa y modifica.

Existe una diferencia entre los objetivos de la construcción de prototipos evolutivos y la de prototipos desechables:

·         El objetivo de la construcción de prototipos evolutivos es entregar a los usuarios finales un sistema funcional.

·         El objetivo de la construcción de prototipos desechables es validar o derivar los requerimientos del sistema. Los requerimientos que son precisos nunca deben estar en el prototipo.

 

INTERFACES DE USUARIO

 

En la actualidad, las interfaces gráficas de usuario se han convertido en la norma para los sistemas interactivos.

La construcción de prototipos es una parte esencial del proceso de diseño de la interfaz de usuario. Las descripciones textuales y los diagramas no son suficientemente buenos para expresar los requerimientos de dicha interfaz. Por lo tanto, la construcción de prototipos evolutivos con la participación del usuario final es la única forma sensible para desarrollar interfaces gráficas de usuario para los sistemas de software.

 

 

Diseño de la interfaz de usuario

 

Para que el sistema tenga éxito, es importante contar con un buen diseño de la interfaz de usuario. Una interfaz difícil de utilizar provocará que los usuarios cometan muchos errores, o simplemente se rehusarán a utilizar el sistema de software sin tomar en cuenta su funcionalidad. Si la información se presenta de una forma confusa o engañosa, los usuarios no comprenderán el significado de la información.

Las ventajas de las GUI’s son:

·         Son relativamente fáciles de aprender y utilizar.

·         Para interactuar con el sistema, los usuarios cuentan con pantallas múltiples.

·         Es posible interactuar rápidamente y tener acceso inmediato a cualquier punto de la pantalla.

 

Principio de diseño de la interfaz de usuario

 

·         Familiaridad del usuario: la interfaz debe utilizar términos y conceptos que se toman de la experiencia de las personas que más utilizan el sistema.

·         Consistencia: la interfaz debe ser consistente en el sentido de que las operaciones comparables se activan de la misma forma.

·         Mínima sorpresa: el comportamiento del sistema no debe provocar sorpresa a los usuarios.

·         Recuperabilidad: la interfaz debe incluir mecanismos para permitir a los usuarios recuperarse de los errores.

·         Guía al usuario: cuando los errores ocurren, la interfaz debe proveer retroalimentación significativa y características de ayuda sensible al contexto.

·         Diversidad de usuarios: la interfaz debe proveer características de interacción apropiada para los diferentes tipos de usuarios del sistema.

 

Interacción del usuario

 

Una interfaz de usuario coherente debe integrar la interacción del usuario y la presentación de la información.

 

Presentación de la información

 

Todos los sistemas interactivos tienen que proveer alguna forma para presentar la información a los usuarios. Una buna recomendación para el diseño de sistemas es mantener separados el software requerido para la presentación de la información de la información misma.

Al separar el sistema de presentación de los datos, se puede cambiar la representación sobre la pantalla del usuario sin tener que cambiar el sistema de cómputo subyacente.

 

Evaluación de la interfaz

 

La evaluación de la interfaz es el proceso de valorar la forma en que se utiliza una interfaz y verificar que cumple sus requerimientos. Por lo tanto, es parte del proceso de verificación y validación de sistemas de software.


UNIDAD Nº 9

“EL FLUJO DE TRABAJO DE REQUERIMIENTOS”

 

 

Cuando un grupo de desarrolladores de software debe desarrollar un nuevo sistema tiene que descubrir por sí mismo lo que se necesita.

Llamamos captura de requisitos a este acto de descubrimiento. Es el proceso de averiguar lo que se debe construir.

 

 

Objeto del FTR

 

El propósito fundamental del FTR es guiar el desarrollo hacia el sistema correcto. Esto se consigue mediante una descripción de los requisitos del sistema suficientemente buena como para que pueda llegarse a un acuerdo entre el cliente y los desarrolladores sobre qué debe y qué no debe hacer el sistema.

 

 

Visión general de la captura de requisitos

 

Este flujo de trabajo incluye los siguientes pasos:

 

·         Enumerar los requisitos candidatos: durante la vida del sistema, los clientes, usuarios y desarrolladores aparecen con buenas ideas que podrían convertirse en verdaderos requerimientos. Se mantiene una lista de estas ideas que crecerá a medida que se añaden nuevos elementos y mengua cuando algunas se convierten en requerimientos y se transforman en otros artefactos como CU.

 

·         Comprender el contexto del sistema: muchas de las personas implicadas en el desarrollo de software requieren un firme conocimiento del contexto en el que se emplaza el sistema. Hay dos formas para expresar el contexto de un sistema:

ü   Modelado del dominio.

ü   Modelado del negocio.

 

·         Capturar RF: la técnica para identificar los requerimientos del sistema se basa en los CU. Para el usuario, un CU es un modo de utilizar el sistema; si los analistas describen todos los CU que necesita el usuario, entonces saben lo que debe hacer el sistema. Como accesorio de los CU, se debe especificar cuál será la apariencia de la interfaz de usuario cuando se lleven a cabo los CU.

 

·         Capturar RNF: los RNF especifican las propiedades del sistema, como restricciones del entorno o de la implementación, rendimiento, dependencias de la plataforma, etc. Estos requerimientos pueden capturarse al principio en el objeto del dominio o del negocio correspondiente en el modelo de contexto del sistema.

 

 

Los requerimientos en el ciclo de vida del software

 

El modelo de CU se desarrolla a lo largo de varios incrementos del desarrollo, donde las iteraciones añadirán nuevos CU y/o añadirán detalle a las descripciones de los CU existentes.

El FTR se hace fundamentalmente durante el inicio y la elaboración.

 

·         Durante la fase de inicio, los analistas identifican la mayoría de los CU para delimitar el sistema y el alcance del proyecto y para detallar los más importantes.

·         Durante la fase de elaboración, los analistas capturan la mayoría de los requerimientos restantes para que los desarrolladores puedan estimar el tamaño del esfuerzo de desarrollo que se requerirá.

·         Los requerimientos restantes se capturan (e implementan) durante la fase de construcción.

·         Casi no hay captura de requerimientos en la fase e transición, a menos que haya requerimientos que cambien.

 

COMPRENSIÓN DEL CONTEXTO

 

Modelo del dominio

 

Un modelo del dominio captura los tipos más importantes de objetos en el contexto del sistema. Los objetos del dominio representan las “cosas” que existen o los eventos que suceden en el entorno en el que trabaja el sistema.

Muchos de los objetos del dominio o clases pueden obtenerse de una especificación de requerimientos o mediante una entrevista con los expertos del dominio.

 

Modelo del negocio

 

El modelo del negocio es una técnica para comprender los procesos de negocio de la organización.

El modelado del negocio está soportado por dos tipos de modelos de UML: modelos de CU y modelos de objetos.

 

Un modelo de CU del negocio describe los procesos de negocio de una empresa en términos de CU del negocio y actores del negocio que se corresponden con los procesos del negocio y los clientes, respectivamente. El modelo de CU del negocio presenta un sistema desde la perspectiva de su uso.

El modelo de CU del negocio se describe mediante diagramas de CU.

 

Un modelo de objetos del negocio es un modelo interno a un negocio. Describe cómo cada CU de negocio es llevado a cabo por parte de un conjunto de TN que utilizan un conjunto de EN y de unidades de trabajo.

Una EN representa algo (como una factura) que los TN toman, inspeccionan, manipulan, producen o utilizan en un CU de negocio.

 

 

 

 

 

 

CAPTURA DE REQUERIMIENTOS COMO CU

 

 

El esfuerzo principal en el FTR es desarrollar un modelo del sistema que se va a construir, y la utilización de los CU es una forma adecuada de crear este modelo. Esto es debido a que los RF se estructuran de forma natural mediante CU, y a que la mayoría de los RNF son específicos de un solo CU, y pueden tratarse en el contexto de ese CU.

 

Vamos a describir el FTR en tres pasos:

·         Artefactos creados.

·         Trabajadores participantes.

·         Actividades.

 

 

ARTEFACTOS

 

Los artefactos fundamentales que se utilizan en el FTR son el modelo de CU, que incluye los CU y los actores. También puede haber otros tipos de artefactos, como prototipo de interfaz de usuario.

 

 

Modelo de CU

 

El modelo de CU permite que los desarrolladores de software y los clientes lleguen a un acuerdo sobre los requerimientos que debe cumplir el sistema. Un modelo de CU es un modelo del sistema que contiene actores, CU y sus relaciones.

 

Actor

 

El modelo de CU describe lo que hace el sistema para cada tipo de usuario. Cada uno de éstos se representa mediante uno o más actores.

Los actores representan terceros fuera del sistema que colaboran con el mismo. Una vez identificados todos los actores, tenemos identificado el entorno externo al sistema.

Los actores suelen corresponderse con TN.

Una instancia de un actor es un usuario concreto que interactúa con el sistema.

 

Caso de Uso

 

Cada forma en que los actores usan el sistema se representa con un CU. Los CU son fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores.

Un CU es una especificación del comportamiento de “cosas” dinámicas (instancias de CU).

 

Descripción de la arquitectura (vista del modelo de CU)

 

La descripción de la arquitectura contiene una vista de la arquitectura del modelo de CU, que representa los CU significativos para la arquitectura.

La vista de la arquitectura del modelo de CU debería incluir los CU que describan alguna funcionalidad importante y crítica, o que impliquen algún requisito importante.

Esta vista de la arquitectura se utiliza como entrada cuando se priorizan los CU para su desarrollo (análisis, diseño, implementación) dentro de cada iteración.

 

Glosario

 

Podemos utilizar un glosario para definir términos comunes importantes que los analistas utilizan al describir el sistema. Un glosario es muy útil para alcanzar un consenso entre los desarrolladores y para reducir en general el riesgo de confusiones.

 

Prototipo de interfaz de usuario

 

Los prototipos de interfaz de usuario nos ayudan a comprender y especificar las interacciones entre actores humanos y el sistema durante la captura de requisitos. Nos ayuda a comprender mejor los CU.

 

 

 

 

TRABAJADORES

 

 

Un trabajador representa una abstracción de un ser humano con ciertas capacidades que se requieren en un CU del negocio.

Podemos identificar tres trabajadores que participan en el modelado de CU:

·         Analista de sistemas.

·         Especificador de CU.

·         Diseñador de interfaz gráfica.

 

 

Analista de sistemas

 

El analista de sistemas es el responsable del conjunto de requerimientos que están modelados en los CU, lo que incluye todos los RF y RNF.

El analista de sistemas es responsable de delimitar el sistema, encontrando los actores y los CU.

El analista de sistemas no es responsable de cada CU en particular; esto es responsabilidad del especificador de CU. El analista de sistemas es también el que dirige el modelado y el que coordina la captura de requerimientos.

 

Especificador de CU

 

El especificador de CU es el encargado de describir detalladamente uno o más CU.

Diseñador de interfaz de usuario

 

Los diseñadores de interfaces de usuario dan forma visual a las interfaces de usuario. Esto puede implicar el desarrollo de prototipos de interfaces de usuario para algunos CU.

 

Arquitecto

 

El arquitecto participa en el FTR para describir la vista de la arquitectura del modelo de CU.

 

 

ACTIVIDADES (flujo de trabajo)

 

 

Primero, el analista de sistemas ejecuta la actividad de “Encontrar Actores y CU” para preparar una primera versión del modelo de CU, con los actores y CU identificados.

Entonces, el arquitecto identifica los CU relevantes para proporcionar entradas a la priorización de CU.

Hecho esto, los especificadotes de CU describen todos los CU que se han priorizado. Más o menos en paralelo, los diseñadores de interfaz de usuario sugieren las interfaces de usuario adecuadas para cada actor basándose en los CU.

Entonces, el analista de de sistemas reestructura el modelo de CU definiendo generalizaciones entre los CU para hacerlo lo más comprensible posible.

Los resultados de la primera iteración a través de este FT consisten en una primera versión del modelo de CU, los CU y cualquier prototipo de interfaz de usuario asociado.

 

 

Encontrar actores y CU

 

Identificamos los actores de los CU para:

·         Delimitar el sistema de su entorno.

·         Esbozar quién y qué (actores) interactuarán con el sistema, y qué funcionalidad (casos de uso) se espera del sistema.

·         Capturar y definir un glosario de términos comunes esenciales para la creación de descripciones detalladas de las funcionalidades del sistema.

La identificación de actores y CU es la actividad más decisiva para obtener adecuadamente los requerimientos, y es responsabilidad del analista de sistemas.

Esta actividad consta de cuatro pasos:

 

·         Encontrar los actores: esta tarea depende de nuestro punto de partida:

ü  A partir de un modelo de negocio: el analista de sistemas puede asignar un actor a cada TN y un actor a cada AN.

ü  A partir de un modelo del dominio: el analista de sistemas identifica los usuarios e intenta organizarlos en categorías representadas por actores.

En ambos casos, se deben identificar los actores que representan sistemas externos y los actores para el mantenimiento y operación del sistema.

El resultado es una nueva versión del artefacto modelo de CU con un conjunto de actores actualizado. Estos actores brevemente descritos pueden utilizarse como punto de partida para encontrar los CU.

 

·         Encontrar los CU: el analista de sistemas va repasando los actores uno por uno y proponiendo los CU para cada uno. Algunos no llegarán a ser CU por sí mismos (podrán ser partes de otros CU). Se elige un nombre para CU (de forma que nos haga pensar en la secuencia de acciones que añade un valor al actor) que suele comenzar con un verbo y debe reflejar el objetivo de la interacción entre el actor y el sistema.

 

·         Describir brevemente cada CU: el analista de sistemas garabatea unas pocas palabras explicando cada CU. Después describe brevemente cada uno.

 

·         Describir el modelo de CU completo: se preparan diagramas y descripciones para explicar el modelo de CU en su totalidad.

 

Priorizar CU

 

El propósito de esta actividad es proporcionar entradas a la priorización de CU ara determinar cuáles son necesarios para el desarrollo en las primeras iteraciones, y cuales pueden dejarse para más tarde.

Los resultados se recogen en la vista de la arquitectura del modelo de CU.

 

Detallar un CU

 

El objetivo principal de detallar cada CU es describir su flujo de sucesos en detalle, incluyendo cómo comienza, termina e interactúan con los actores.

El especificador de CU detalla paso a paso la descripción de cada CU en una especificación precisa de la secuencia de acciones.

 

Prototipar la interfaz de usuario

 

El objetivo de esta actividad es construir un prototipo de interfaz de usuario.

El resultado final de esta actividad es un conjunto de esquemas de interfaces de usuario y prototipos de interfaces de usuario que especifican la apariencia de esas interfaces de cara a los actores más importantes.

 

Estructurar el modelo de CU

 

El modelo de CU se estructura para:

Extraer descripciones de funcionalidad generales y compartidas que pueden ser utilizadas por descripciones más específicas (generalizaciones).

Extraer descripciones de funcionalidad adicionales u opcionales que pueden extraer descripciones más específicas (inclusiones y extensiones).

 

 

PATRONES DE CU

 

Un patrón es una solución a un problema. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable a diferentes problemas de en distintas circunstancias.

 

 

Descripción de patrones

 

Los patrones se describen mediante:

·         Nombre.

·         Gráfico.

·         Contexto.

·         Definición del problema.

·         Historia metafórica.

·         Fuerzas que afectan el problema.

·         Solución.

·         Ejemplos.

 

 

Organización del lenguaje de los patrones de CU

 

  • Consiste en 31 patrones
  • Conforman dos categorías:

ü  Patrones de Desarrollo: describen características de práctica de escritura de CU probadas, y ofrecen criterios para medir la calidad del proceso de escritura de CU.

ü  Patrones Estructurales: describen los componentes básicos de los CU, explicando cómo deberían ser organizados y ofrecen criterios para juzgar un CU.

 

Patrones estructurales

 

  • Conjunto de CU: describen el comportamiento de un sistema y consisten en un conjunto de CU, cada uno de los cuales describe un servicio útil que un actor individual necesita.
  • Casos de Uso: cada CU es una colección de escenarios que puestos juntos describen todas las formas que un actor tiene que alcanzar o fracasar en alcanzar el objetivo.
  • Escenarios y Pasos: los escenarios consisten de pasos cada uno describiendo una acción que el actor o el sistema debe hacer para acercar al actor a su objetivo.
  • Relaciones de CU: los CU a menudo interactúan con otros CU. Los patrones de relación describen técnicas para manejar comportamiento repetitivo o excesivamente complejo.

 

Patrones de desarrollo

 

Las culturas individuales y organizacionales hacen difícil definir un proceso universal para escribir CU.

Estos patrones identifican algunas buenas características para el desarrollo efectivo de CU.

Estos patrones se dividen en tres subcategorías:

  • De equipo: composición de los equipos que escriben CU.
  • De proceso: técnicas para crear un conjunto de CU.
  • De edición: técnicas para mejorar CU existentes.

 

 

 

 

PATRONES DE SOFTWARE

 

Podemos reusar las experiencias, soluciones de análisis y diseño que ya hemos aplicado anteriormente.

Los patrones realizan una descripción de un problema que ocurre y de cómo solucionarlo. Son estereotipos que utilizamos una y otra vez para solucionar problemas parecidos; y es posible perfeccionarlos.

Un patrón no busca lo particular, sino la esencia.

El objetivo que se persigue es tener un catálogo de patrones estandarizados.

 

Componentes de un patrón

 

·         Nombre.

·         Propósito.

·         Sinónimo.

·         Colaboraciones.

·         Contexto.

·         Explicación.

·         Fuerzas.

·         Motivación.

·         Ejemplos.

·         Patrones relacionados.

·         Aplicabilidad.

·         Estructura.

·         Participantes.

·         Consecuencias.

 

Tipos de patrones

 

·         Estructural (estático): sirven para modelar el dominio (diagrama de clases).

·         GRASP: sirve para modelar un comportamiento dinámico (configurar el diagrama de colaboración y definir responsabilidades de las clases).

 

Patrones para la construcción del dominio

 

·         Patrón fundamental (Colección – Trabajador)

·         Patrones transaccionales (Jugador – Transacción)

ü   Actor – Participante

ü   Participante – Tx

ü   Lugar - Tx

·         Patrones de agregación: manejan relaciones de agregación.

ü   Contenedor – Contenido

ü   Contenedor – DetalleContenido

ü   Grupo – Miembro

ü   Etc.

·         Patrones de plan: manejan relaciones con los involucrados en un plan.

ü   Plan – Paso

ü   Plan – EjecuciónPlan

ü   Etc.

 

 


UNIDAD Nº 10

“EL FLUJO DE TRABAJO DE ANÁLISIS”

 

 

Durante el análisis, se analizan los requerimientos que se describieron en la captura de requerimientos, refinándolos y estructurándolos. El objetivo de hacerlo es conseguir una mejor comprensión más precisa de los requerimientos y una descripción de los mismos que sea fácil de mantener y que nos ayude a estructurar el sistema entero.

Para comunicar de manera eficiente las funciones del sistema al cliente:

·         Los CU deben mantenerse tan independientes unos de otros como sea posible.

·         Los CU deben describirse utilizando el lenguaje del cliente.

·         Debe estructurarse cada CU  para que forme una especificación de funcionalidad completa.

 

Dados esos temas, el propósito del análisis es resolverlos analizando los requerimientos con mayor profundidad, pero con la gran diferencia de que puede utilizarse el lenguaje de los desarrolladores para describir los resultados.

En el análisis podemos razonar más sobre los aspectos internos del sistema.

La estructura de los requisitos que proporciona el análisis también sirve como entrada fundamental para dar forma al sistema en su totalidad.

 

 

Modelo de análisis

 

El lenguaje que utilizamos en el análisis se basa en un modelo de objetos conceptual, que llamamos modelo de análisis. El modelo de análisis nos ayuda a refinar los requisitos y nos permite razonar sobre los aspectos internos del sistema.

El modelo de análisis también nos ayuda a estructurar los requisitos y nos proporciona una estructura centrada en el mantenimiento.

El modelo de análisis puede considerarse una primera aproximación al modelo de diseño, aunque es un modelo por sí mismo.

Sin embargo, es importante hacer notar que el modelo de análisis hace abstracciones y evita resolver problemas y tratar algunos requisitos que es mejor posponer al diseño y a la implementación.

 

 

Por qué el análisis no es diseño ni implementación

 

El diseño y la implementación son mucho más que el análisis (refinamiento y estructuración de los requerimientos), por lo que se requiere una separación de intereses.

El diseño y la implantación son mucho más que simplemente el analizar los requerimientos; el diseño y la implementación se preocupan en realidad de dar forma al sistema de manera que dé vida a todos los requerimientos (incluidos los RNF) que incorpora.

Antes de comenzar a diseñar e implementar deberíamos contar con una comprensión precisa y detallada de los requerimientos, lo cual se logra en el análisis.

 

 

Modelo de análisis: resumen

 

·         Ofrece una especificación más precisa de los requerimientos.

·         Se describe utilizando el lenguaje de los desarrolladores.

·         Estructura los requerimientos de un modo que facilita su comprensión, su preparación, su modificación y su mantenimiento.

·         Puede considerarse una primera aproximación al modelo de diseño.

·         Proporciona una vista interna del sistema.

·         Está estructurado por clases y paquetes.

·         Es utilizado fundamentalmente por los desarrolladores para comprender cómo debería darse forma al sistema.

·         No debería contener redundancias, inconsistencias, etc.

·         Define realizaciones de CU y cada una de ellas representa el análisis de un CU.

 

 

El análisis en el ciclo de vida del software

 

Las iteraciones iniciales de la elaboración se centran en el análisis. Eso contribuye a obtener una arquitectura estable y sólida y facilita una comprensión en profundidad de los requerimientos. Al término de la fase de elaboración y durante la construcción, el énfasis pasa al diseño y a la implementación.

La manera de ver y emplear el análisis puede diferir de un proyecto a otro:

 

  • El proyecto utiliza el modelo de análisis para describir los resultados del análisis, y mantiene la consistencia de este modelo a lo largo de todo el ciclo de vida del software.
  • El proyecto utiliza el modelo de análisis para describir los resultados del análisis, pero considera a este modelo como una herramienta transitoria e intermedia.
  • El proyecto no utiliza en absoluta el modelo de análisis para describir los resultados del análisis (el proyecto analiza los requerimientos en la captura de requerimientos o en el diseño).  [Debe considerarse esta variante en sistemas muy simples].

 

 

ARTEFACTOS

 

Clase del análisis

 

Una clase de análisis representa una abstracción de una o varias clases y/o subsistemas del diseño del sistema. Esta abstracción posee las siguientes características:

·         Una clase de análisis se centra en el tratamiento de los RF.

·         Una clase de análisis raramente define su comportamiento mediante responsabilidades en un nivel más alto y menos formal (una responsabilidad es una descripción textual de un conjunto cohesivo del comportamiento de una clase).

·         Una clase de análisis define atributos. Los atributos identificados durante el análisis con frecuencia pasan a ser clases en el diseño y la implementación.

·         Una clase de análisis participa en relaciones.

·         Las clases de análisis siempre encajan en uno de tres estereotipos básicos:

 

ü  De interfaz: se utilizan para modelar la interacción entre el sistema y sus actores. Esta interacción a menudo implica recibir (y presentar) información y peticiones de (y hacia) los usuarios y los sistemas externos. Las clases de interfaz modelan las partes del sistema que dependen de sus actores. Representan a menudo abstracciones de ventanas, formularios, paneles, etc. Cada clase de interfaz debería asociarse con al menos un actor (y viceversa).

                                                        

 

ü  De entidad: se utilizan para modelar información que posee una vida larga y que es a menudo persistente. Modelan la información y el comportamiento asociado de algún fenómeno o concepto, como una persona, un objeto del mundo real, o un suceso. En muchos casos, las clases de entidad se derivan de una clase de EN, o de una clase del dominio; tomada del modelo de objetos de negocio, o del modelo del dominio. La diferencia entre una clase de entidad y una clase de EN es que la primera representan objetos manejados por el sistema, mientras que la segunda representan objetos presentes en el negocio y en el dominio del problema.

 

 

 

ü  De control: representan coordinación, secuencia, transacciones y control de otros objetos y se usan con frecuencia para encapsular el control de un CU en concreto. Se utilizan para representar derivaciones y cálculos complejos que no pueden asociarse con una clase de entidad concreta.

                                                       

Realización de caso de uso-análisis

 

Una realización de caso de uso – análisis es una colaboración dentro del modelo de análisis que describe cómo se lleva a cabo y se ejecuta un CU en términos de las clases del análisis y de sus objetos del análisis en interacción. Una realización de CU proporciona por tanto una traza directa hacia un CU concreto del modelo de CU.

 

Diagramas de clases

Una clase del análisis y sus objetos normalmente participan en varias realizaciones de CU. Por tanto, es importante coordinar todos los requisitos sobre una clase y sus objetos que pueden tener diferentes CU. Para esto, se adjuntan diagramas de clases a las realizaciones de CU.

 

Diagramas de interacción

La secuencia de acciones en un CU comienza cuando un actor invoca el CU mediante el envío de algún tipo de mensaje al sistema. En el análisis se prefiere mostrar esto con diagramas de colaboración, ya que el objetivo es identificar requisitos y responsabilidades sobre los objetos, y no identificar secuencias de interacción.

En los diagramas de colaboración, se muestran las interacciones entre objetos creando enlaces entre ellos y añadiendo mensajes a estos enlaces.

 

Dentro de una realización de CU, objetos diferentes tienen diferentes ciclos de vida:

·         Un objeto de interfaz no tiene por qué ser particular de una realización de CU. Sin embargo, los objetos de interfaz a menudo se crean y finalizan dentro de una sola realización de CU.

·         Un objeto de entidad normalmente no es particular de una realización de CU.

·         Las clases de control suelen encapsular el control asociado con un CU concreto, lo cual implica que debería crearse un objeto de control cuando el CU comienza y destruirse cuando el CU termina. Sin embargo, hay excepciones, como cuando un objeto de control participa en más de una realización de CU, cuando varios objetos de control participan en una misma realización de CU, y cuando una realización de CU no requiere ningún objeto de control.

 

Paquete del análisis

 

Los paquetes del análisis proporcionan un medio para organizar los artefactos del modelo de análisis en piezas manejables. Puede constar de clases de análisis, de realizaciones de CU, y de otros paquetes del análisis.

Los paquetes del análisis tienen las siguientes características:

·         Pueden representar una separación de intereses de análisis.

·         Deberían crearse basándonos en los RF y en el dominio del problema.

·         Probablemente se convertirán en subsistemas en las dos capas de aplicación superiores del modelo de diseño.

 

Paquetes de servicio

En el PUD, el concepto de servicio está soportado por los paquetes de servicio. Los paquetes de servicio se utilizan para estructurar el sistema de acuerdo a los servicios que proporciona.

 

 

Descripción de la arquitectura (vista del modelo de análisis)

 

La descripción de la arquitectura contiene una vista de la arquitectura del modelo de análisis, que muestra sus artefactos significativos para la arquitectura.

Los siguientes artefactos del modelo de análisis normalmente se consideran significativos para la arquitectura:

La descomposición del modelo de análisis en paquetes de análisis y sus dependencias.

Las clases fundamentales del análisis como las clases de entidad, las clases de interfaz, las clases de control y las clases del análisis que son generales.

Realizaciones de CU que describen cierta funcionalidad importante y crítica que se centran en un CU importante, que probablemente se encuentra en la vista de la arquitectura del modelo de CU.

 

 

 

 

 

TRABAJADORES

 

       

 

Arquitecto

 

El arquitecto es el responsable de la integridad del modelo de análisis, garantizando que éste sea correcto, consistente y legible como un todo.

El arquitecto es responsable de lo que es significativo para la arquitectura (descripción de la arquitectura).

Es también responsable de la arquitectura del modelo de análisis.

El arquitecto no es responsable del desarrollo y mantenimiento de los artefactos del modelo de análisis.

 

 

Ingeniero de casos de uso

 

Un ingeniero de CU es responsable de la integridad de una o más realizaciones de CU, garantizando que cumplen los requerimientos que recaen sobre ellos.

Es también responsable del diseño de las realizaciones de los CU (por lo tanto, es responsable tanto del análisis como del diseño del CU).

El ingeniero de CU no es responsable de las clases de análisis ni de las relaciones que se usan en la realización del CU.

 

 

Ingeniero de componentes

 

El ingeniero de componentes define y mantiene las responsabilidades, atributos, relaciones y requerimientos especiales (RNF) de una o varias clases del análisis.

También mantiene la integridad de uno o varios paquetes del análisis, garantizando que sus contenidos son correctos.

 

 

 

ACTIVIDADES (flujo de trabajo)

 

 

 

 

Los arquitectos comienzan la creación del modelo de análisis identificando los paquetes de análisis principales, las clases de entidad y los requisitos comunes. Después, los ingenieros de CU realizan cada CU en términos de las clases del análisis participantes exponiendo los requisitos de comportamiento de cada clase. Los ingenieros de componentes especifican posteriormente estos requisitos y los integran dentro de cada clase creando responsabilidades, atributos y relaciones para cada clase.

El arquitecto identifica de manera continua nuevos paquetes del análisis, clases y requisitos comunes, y los ingenieros de componentes responsables de los paquetes del análisis continuamente los refinan y mantienen.

Análisis de la arquitectura

 

El propósito del análisis de la arquitectura es esbozar el modelo de análisis y la arquitectura mediante la identificación de paquetes del análisis, clases del análisis y requisitos especiales.

 

 

Identificación de paquetes del análisis

Los paquetes del análisis proporcionan un medio para organizar el modelo de análisis en piezas más pequeñas y más manejables.

Una identificación inicial de los paquetes del análisis se hace basándonos en los RF y en el dominio del problema. Debido a que capturamos los RF en la forma de CU, una forma directa de identificar paquetes del análisis es asignar la mayor parte de un cierto número de CU a un paquete concreto. Entre las “asignaciones” adecuadas de CU a un paquete tenemos:

·         CU requeridos para dar soporte a un determinado proceso de negocio.

·         CU requeridos para dar soporte a un determinado actor del sistema.

·         CU que está relacionado mediante relaciones de generalización y de extensión.

 

 

Identificación de clases de entidad obvias

Suele ser adecuado prepara una propuesta preliminar de las clases de entidad más importante basado en las clases del dominio o la EN que se identificaron durante la captura de requerimientos. Sin embargo, la mayoría de las clases se identificarán al crear las realizaciones de los CU.

 

 

Identificación de requisitos especiales comunes

Un requisito especial es un requisito que aparece durante el análisis y que es importante anotar de forma que pueda ser tratado en las actividades de diseño e implementación.

Ejemplos:

·         Persistencia.

·         Distribución y concurrencia.

·         Características de seguridad.

·         Tolerancia a fallos.

·         Gestión de transacciones.

 

 

 

Analizar un caso de uso

 

Analizamos un CU para:

·         Identificar las clases del análisis.

·         Distribuir el comportamiento del CU entre los objetos del análisis que interactúan.

·         Capturar requisitos especiales.

 

Otra forma de llamar al análisis de CU es refinamiento de CU. Refinamos cada CU como colaboración de clases del análisis.

 

Identificación de clases del análisis

Identificamos las clases de control, entidad e interfaz necesarias para realizar los CU y esbozamos sus nombres, responsabilidades, atributos y relaciones.

Los CU descritos en los requisitos no siempre están suficientemente detallados, por lo tanto, puede que tengamos que refinar las descripciones de los CU.

 

Descripción de interacciones entre objetos del análisis

Cuando tenemos un esbozo de las clases necesarias para realizar el CU, debemos describir cómo interactúan sus correspondientes objetos del análisis. Esto se hace mediante diagramas de colaboración.

 

Captura de requisitos especiales

Recogemos todos los requisitos sobre una realización de CU que se identifican en el análisis, pero deberían tratarse en el diseño y en la implementación.

Debemos hacer referencia si es posible a los requisitos especiales comunes que habían sido identificados por el arquitecto.

 

 

Analizar una clase

 

Los objetivos de analizar una clase son:

 

·         Identificar y mantener las responsabilidades de una clase del análisis.

·         Identificar y mantener los atributos y relaciones de la clase de análisis.

·         Capturar requisitos especiales sobre la realización de la clase de análisis.

 

 

Identificar responsabilidades

Las responsabilidades de una clase pueden recopilarse combinando todos los roles que cumple en diferentes realizaciones de CU. Podemos identificar todas las realizaciones de Cu en las cuales participa la clase mediante el estudio de sus diagramas de clase y de interacción.

 

Identificación de atributos

 Un atributo especifica una propiedad de una clase de análisis, y normalmente es necesaria para las responsabilidades de su clase.

 

Identificación de asociaciones y agregaciones

Los objetos del análisis interactúan unos con otros mediante enlaces. Estos enlaces suelen ser instancias de asociaciones entre sus correspondientes clases. El ingeniero de componentes debería estudiar los enlaces empleados para determinar qué asociaciones son necesarias. Los enlaces pueden implicar la necesidad de referencias y agregaciones entre objetos.

 

Identificación de generalizaciones

 Las generalizaciones deberían utilizarse durante el análisis para extraer comportamiento compartido y común entre varias clases del análisis diferentes.

 

Captura de requisitos especiales

Recogeremos todos los requisitos de una clase del análisis que se han identificado en el análisis, pero que deberían tratarse en el diseño y en la implementación.

Debemos hacer referencia si es posible a cualquier requisito especial común identificado por el arquitecto.

 

 

Analizar un paquete

 

Los objetivos de analizar un paquete son:

 

·         Garantizar que el paquete del análisis es tan independiente de otros paquetes como sea posible.

·         Garantizar que el paquete del análisis cumple su objetivo de realizar algunas clases del dominio o CU.

·         Describir las dependencias.

 

 

 

INTERACCIONES

 

Los objetos interactúan entre sí pasándose mensajes. Una interacción es un comportamiento que incluye un conjunto de mensajes intercambiados por un conjunto de objetos dentro de un contexto para lograr un propósito.

Las interacciones se utilizan para modelar los aspectos dinámicos de las colaboraciones.

Las interacciones incluyen los mensajes enviados entre objetos. Un mensaje implica la invocación de una operación o el envío de una señal.

 

Enlaces

 

Un enlace es una conexión semántica entre objetos.

Un enlace especifica un camino a lo largo del cual un objeto puede enviar un mensaje a otro objeto.

Mensajes

 

Un mensaje es la especificación de una comunicación entre objetos que transmite información, con la expectativa de que se desencadenará una actividad. La recepción de una instancia de un mensaje puede considerarse una instancia de un evento.

En UML se pueden modelar varios tipos de acciones:

·         Llamada.

·         Retorno.

·         Envío.

·         Creación.

·         Destrucción.

 

Secuenciación

 

Cuando un objeto envía un mensaje a otro, el objeto receptor puede, a su vez, enviar un mensaje a otro objeto, el cual puede enviar un mensaje a otro objeto diferente. Este flujo de mensajes forma una secuencia.

 

Representación

 

Cuando se modela una interacción, normalmente se incluirán tanto objetos como mensajes.

Los objetos y mensajes implicados en una interacción se pueden visualizar de dos formas:

·         Destacando la ordenación temporal de sus mensajes (diagrama de secuencia).

·         Destacando la organización estructural de los objetos que envían y reciben los mensajes (diagrama de colaboración).

 

 

 

 

 

 

DIAGRAMAS DE INTERACCIÓN

 

Un diagrama de interacción muestra una interacción, que consiste en un conjunto de objetos y sus relaciones, incluyendo los mensajes que se pueden enviar entre ellos.

Un diagrama de secuencia es un diagrama de interacción que destaca la ordenación temporal de los mensajes.

Un diagrama de colaboración es un diagrama de interacción que destaca la organización estructural de los objetos que envían y reciben mensajes.

Los diagramas de interacción no son sólo importantes para modelar los aspectos dinámicos de un sistema, sino también para construir sistemas ejecutables por medio de ingeniería directa e inversa.

 

Contenidos

 

Normalmente, los diagramas de interacción contienen:

  • Objetos.
  • Enlaces.
  • Mensajes.

 

 

Diagramas de secuencia

 

Un diagrama de secuencia destaca la ordenación temporal de los mensajes.

Tienen dos características que los distinguen de los diagramas de colaboración: en primer lugar, está la línea de vida, que representa la existencia de un objeto a lo largo de un período de tiempo. En segundo lugar, está el foco de control, que representa el período de tiempo durante el cual un objeto ejecuta una acción.

 

 

Diagramas de colaboración

 

Un diagrama de colaboración destaca la organización de los objetos que participan en una interacción.

Los diagramas de colaboración tienen dos características que los distinguen de los diagramas de secuencia: en primer lugar, el camino. En segundo lugar, está la secuencia. Para indicar la ordenación temporal de un mensaje, se precede de un número.

En un diagrama de colaboración interactúan objetos, no clases.

Se hace un diagrama de colaboración por cada escenario del CU que el diagrama describe.

 

 

INGENIERÍA DIRECTA E INVERSA

 

La ingeniería directa es la creación de código a partir de un modelo.

La ingeniería inversa es la creación de un modelo a partir de código.

 

 

MÁQUINAS DE ESTADO

 

El comportamiento de una sociedad de objetos que colaboran puede ser modelado mediante una interacción. El comportamiento de un objeto individual puede ser modelado mediante una máquina de estados.

Una máquina de estados es un comportamiento que especifica las secuencias de estados por las que pasa un objeto durante su vida, en respuesta a eventos, junto con sus respuestas a esos eventos.

 

 

Estados

 

Un estado es una condición o situación en la vida de un objeto durante la cual satisface alguna condición, realiza alguna actividad o espera algún evento. Un objeto permanece en un estado durante una cantidad finita de tiempo.

El estado inicial indica el punto de comienzo por defecto para la máquina de estados; y el estado final indica que la ejecución de la máquina de estado o del estado que lo contiene ha finalizado.

 

 

Transiciones

 

Una transición es una relación entre dos estados que indica que un objeto que esté en el primer estado realizará ciertas acciones y entrará en el segundo estado cuando ocurra un evento especificado y se satisfagan una condiciones especificadas.

 

Diagramas de estados

 

Un diagrama de estados muestra una máquina de estados.

Un diagrama de actividades es un caso especial de diagrama de estados en el cual todos o la mayoría de los estados son estados de actividad y todas o la mayoría de las transiciones se disparan por la terminación de las actividades en el estado de origen.

 

 

COLABORACIONES

 

Una colaboración denota una sociedad de clases, interfaces y otros elementos que colaboran para proporcionar algún comportamiento cooperativo.

Las colaboraciones se utilizan para especificar la realización de CU y operaciones.

 

 

Estructura

 

Las colaboraciones tienen dos aspectos:

·         Una parte estructural que especifica las clases, interfaces y otros elementos que colaboran para llevar a cabo la colaboración a la que se da nombre.

·         Una parte de comportamiento que especifica la dinámica de cómo interactúan esos elementos.

 

 

 

 

 

 

Comportamiento

 

Mientras que la parte estructural de una colaboración se representa normalmente mediante un diagrama de clases, la parte de comportamiento de una colaboración se representa mediante un diagrama de interacción.

Si se quiere destacar la ordenación temporal de los mensajes, se puede utilizar un diagrama de secuencia. Si se quiere destacar las relaciones estructurales entre los objetos que colaboran, se puede utilizar un diagrama de colaboración.

 

 

Organización de colaboraciones

 

Hay dos tipos de relaciones que tienen que ver con las colaboraciones:

·         Relación entre la colaboración y el elemento al que realiza: una colaboración puede realizar un clasificador o una operación. Por ejemplo, un CU puede ser realizado por una colaboración; ese CU, incluido sus actores, y los CU con los que está relacionado, proporcionan un contexto para la colaboración.

·         Relación entre colaboraciones: unas colaboraciones pueden refinar a otras, y esta relación se modela como un refinamiento. La relaciones de refinamiento entre colaboraciones normalmente reflejan las relaciones de refinamiento entre CU que representan.

 

 

10Valor
7377Visitas
Comentarios
Por favor inicia sesión para comentar.