El modelo de casos de uso. Ingeniería de la Programación

Save this PDF as:
 WORD  PNG  TXT  JPG

Tamaño: px
Comenzar la demostración a partir de la página:

Download "El modelo de casos de uso. Ingeniería de la Programación"

Transcripción

1 El modelo de casos de uso Ingeniería de la Programación Prácticas cas 1

2 Contenidos Introducción RF y RNF Introducción al modelo de RF de UML. Actores y Casos de Uso Modelo de casos de uso Diagrama de contexto y modelo inicial. Plantillas de especificación. Modelo estructurado. Relaciones entre actores y casos de uso Proceso de construcción del modelo de casos de uso Documento de Requisitos. 2

3 Objetivos Introducir los conceptos de requerimientos de usuario y del sistema. Describir los requisitos funcionales y los no funcionales. Explicar el modo de organizar los requerimientos en un documento de requerimientos. Qué tipo de requerimientos se incluyen en UML?. Tópicos descritos: Requerimientos funcionales y no funcionales. Requerimientos de usuario. Requerimientos del sistema. El documento de especificación de requisitos. 3

4 Introducción RF y RNF La ingeniería de requisitos describe el proceso de establecer los servicios que los clientes requieren de un sistema, las condiciones bajo las que funcionará o las condiciones que se aplican al proceso de desarrollo. Los requerimientos son las descripciones de los servicios del sistema, las condiciones de funcionamiento y las condiciones de desarrollo. 4

5 Introducción: qué es un requerimiento? e Puede ser tanto la descripción de alto nivel o muy detallada de un servicio, de una restricción del futuro sistema o del proceso de desarrollo. Los requerimientos tienen una función dual: Se pueden utilizar como base para solicitar ofertas de desarrollo; por tanto pueden estar sujetos a interpretación. Pueden ser la base del contrato de desarrollo; por tanto deben ser muy detallados. d 5

6 Tipos de requerimientos (usuario versus esussste sistema). Requerimientos de usuario Sentencias en lenguaje natural de los servicios que el sistema debe proporcionar junto a sus restricciones de operación. Escrito por clientes. Requerimientos del sistema. Un documento estructurado con una descripción detallada de la funcionalidad del sistema y de las restricciones de operación. Define qué debe ser implementado, de modo que puede ser parte de un contrato entre el cliente y el desarrollador. 6

7 Requerimientos funcionales y no funcionales (1) Requerimientos funcionales: Sentencias describiendo los servicios que el sistema debe proporcionar o cómo debe reaccionar frente a entradas proporcionadas. Dependiendo del caso también pueden describirse los tipos de usuarios del sistema. Ejemplo: Sistema de búsqueda de artículos científicos en BD. El usuario puede efectuar sus búsquedas en el conjunto inicial de bases de datos o bien seleccionar un subconjunto de las mismas. El sistema debe proporcionar un conjunto conveniente de visores de documentos para que los artículos puedan ser consultados en-línea. 7

8 Requerimientos funcionales y no funcionales (2) Requerimientos no funcionales (RNF): Los requerimientos no funcionales establecen cualidades o atributos que debe poseer el sistema. Expresan propiedades y restricciones sobre los servicios o funciones ofertadas por el sistema (como restricciones temporales), o sobre el proceso de desarrollo (estándares que deben cumplirse). Ejemplos de NFR: seguridad, usabilidad, fiabilidad. 8

9 Requerimientos funcionales y no funcionales (3) Algunas veces no hay una distinción clara entre RF y RNF ya que depende de la forma en la que se exprese el requerimiento. Ejemplo: El sistema debe garantizar que los datos se encuentran protegidos frente a accesos no autorizados. -> RNF. El sistema incluirá un procedimiento de autenticación donde d los usuarios proporcionaran un login y password. Únicamente los usuarios autenticados pueden acceder a los datos -> RF. 9

10 Clasificación de los requerimientos NFR Existen diversas taxonomías para clasificar los RNF. McCall & Matsumoto factores de calidad. ISO IEEE Std 830. VOLERE. D. Firesmith. I. Sommerville. 10

11 Clasificación de RNF Requerimientos del producto. Especifican que el producto deben comportarse de forma particular, por ej. velocidad de ejecución, fiabilidad, etc. Requerimientos de la organización. Requerimientos que son consecuencia de las políticas y procedimientos de la organización, por ej. estándares utilizados, requerimientos de implementación, etc. Requerimientos i externos. Requerimientos cuyo origen son factores externos al sistema y al proceso de desarrollo del mismo, por ej. requerimientos de interoperabilidad, legislación, etc. 11

12 Ejemplos: Requerimientos del proceso El proceso de desarrollo que va a utilizarse debe definirse de manera precisa y debe ser consistente con las normas ISO El sistema debe ser desarrollado y documentado utilizando la herramienta IBM-Telelogic Tau. Deben generarse informes cada 2 semanas indicando el avance en el desarrollo del sistema. 12

13 Ejemplos: Requerimientos externos La oficina de protección de datos debe certificar que todos los datos se almacenan y gestionan de acuerdo a la ley de protección de datos. El sistema no debe mostrar a los operadores del mismo ninguna información de los clientes, salvo el nombre y el número de cliente. 13

14 Introducción al modelo de RF de UML Introducidos por I. Jacobson en Objectory en Los casos de uso describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista de los usuarios. Son descripciones de la funcionalidad del futuro sistema independientes de la implementación. Sirven para modelar los requisitos funcionales de un sistema software. 14

15 Introducción al modelo de RF de UML Por qué casos de uso? Fácilmente compresibles por clientesusuarios. Se utilizan como base para un desarrollo iterativo e incremental. Incorporados en la mayor parte de lo métodos de desarrollo OO de segunda generación. 15

16 Actores y Casos de Uso Los actores definen qué existe fuera del sistema Entorno del sistema Sistema Caso de uso Empleado Caso de uso Sistema Au torizaciones Caso de uso Comunicación Un actor puede ser una persona, un conjunto de personas, un sistema hardware, un sistema software o un reloj. 16

17 Actores Un actor representan un rol que puede desempeñar alguien o algo que necesita intercambiar información con el sistema. Cliente Bancario Una misma persona puede jugar varios roles al interactuar t con el sistema y un mismo rol puede corresponder con varias personas. 17

18 Casos de uso Un caso de uso describe una forma concreta de utilizar parte de la funcionalidad del sistema. La colección de todos los casos de uso describe toda la funcionalidad del sistema. Extracción de dinero del cajero Ingreso de dinero en el cajero Consulta de saldo 18

19 Caso de uso (definición) I. Jacobson propone p dos definiciones: Documento que describe una secuencia de eventos que realiza un actor (agente externo) que usa el sistema para llevar a cabo un proceso que tiene algún valor para el. Cada caso de uso está formado por una secuencia de eventos, iniciada por un actor, que describe la interacción que tiene lugar entre el actor y el sistema. 19

20 Caso de uso Características: Son iniciados por un actor (actor primario o principal). Pueden participar otros actores (secundarios) Poseen un nombre. Pueden contener condiciones de inicio (precondiciones) y condiciones de terminación (postcondiciones) La descripción del caso de uso contiene la secuencia de eventos (pasos del caso de uso). 20

21 Caso de uso (notación) La comunicación entre actores y casos de uso se muestra de la forma: Cliente Bancario Extracción de dinero del cajero 21

22 Modelo de casos de uso Notación gráfica con actores y casos de uso. Relaciones Entre actores: herencia. Entre actores y casos: asociación. Entre casos de uso: Usa, extiende (UML 1.3) Incluye, extiende, hereda de (UML 1.5) Incluye, extiende, hereda de (UML 2.0) Descripción: plantillas textuales para cada caso de uso. 22

23 Notación gráfica El modelo de casos de uso muestra gráficamente toda la funcionalidad del sistema. Alta Cliente extiende Buscar Cliente incluye Introducir Pedido extiende extiende Obtener Estado Pedido Pago en cuenta Pago con tarjeta Empleado incluye Buscar Pedido Cancelar Pedido incluye 23

24 Organización del modelo Estructurado en tres capas: Diagrama de contexto y modelo inicial. Representaciones gráficas. Plantillas de descripción. Representación textual. Modelo estructurado. Representación gráfica. 24

25 Diagrama de contexto. El diagrama de contexto muestra los límites del sistema y los actores (agentes externos) )que interactuarán con el mismo. Terminal Punto de Venta Empleado Cliente Proveedor Responsable de compras Director Comercial 25

26 Modelo inicial Contiene la agrupación jerárquica de los distintos casos de uso: Mediante paquetes UML (subsistemas). ste Biblioteca Préstamos Socios 26

27 Modelo inicial (2) O bien: Sistema de Pedidos Gestión Pedidos Gestión de Artículos Empleado Nuevo Pedido Cancelar Pedido Estado Pedido Nuevo Producto Borrar Producto Gestión de Clientes Administrador Borrar Pedido Buscar Pedidos Nuevo Cliente Buscar Cliente 27

28 Modelo inicial (3) Utilizando un árbol de descomposición funcional. Sistema de Pedidos Gestión Pedidos Gestión Artículos Gestión Clientes Nuevo Pedido Nuevo Producto Cancelar Pedido Borrar Producto Estado Pedido Borrar Pedido Buscar Pedidos 28

29 Plantillas de descripción Los casos de uso se describen utilizando plantillas en lenguaje natural. Habitualmente: Nombre del CU. Descripción. Actores (primario y secundarios) Precondiciones, Postcondiciones. Flujo de eventos. 29

30 Ejemplo TPV Para un terminal punto de venta: Un terminal punto de venta (TPV) es un sistema computerizado usado para registrar las ventas y gestionar pagos. Se usa en supermercados y en grandes almacenes. Incluye componentes hardware (como el ordenador y el escáner e del código de barras) as) y software para ejecutar el sistema. 30

31 Ejemplo TPV (2) Diagrama de contexto y modelo inicial Terminal Punto de Venta Iniciar Sesión Empleado Venta Productos Cliente Devolver productos Acabar Sesión Director Comercial Responsable de compras Compra proveedores Proveedor Hacer ofertas Fijar Precio 31

32 Ejemplo TPV (3) Variaciones sobre el ejercicio: Supermercado tradicional Iniciar Sesión Empleado Venta Productos Cliente Devolver productos Supermercado electrónico Venta Productos Devolver productos Cliente 32

33 Plantillas TPV Empleado Venta Productos Cliente Empleado Venta Productos Si únicamente se desea mostrar la interacción de los actores con el sistema informático. 33

34 Plantilla TPV Caso de uso Venta de Productos Actores Cliente (iniciador), Empleado Propósito Capturar una venta y su pago en efectivo Resumen Un cliente llega a la caja con productos para comprar. El empleado registra los productos y gestiona el pago en efectivo. Al acabar el cliente se va con los productos. Precondiciones El empleado se ha identificado en el sistema. Postcondiciones La venta se almacena en el sistema. Incluye - Extiende - Hereda de - 34

35 Plantilla TPV Intenciones de usuario Obligaciones del sistema 1. El caso de uso se inicia cuando un cliente llega a la caja con productos. 2. El empleado indica que 3. El sistema registra el comienza una nueva venta. inicio de una venta 4. Mientras queden artículos: El 5. El sistema determina el empleado introduce el código de precio del producto y añade cada producto y la cantidad la información a la cuenta. 6. El empleado indica el fin de la 7. El sistema calcula y venta muestra el total. 8. El empleado dice el total t al cliente. 9. El cliente entrega el importe 10. El empleado indica el dinero 11. El sistema calcula y que ha recibido muestra el cambio. Imprime un recibo y registra la venta. 12. El empleado deposita el dinero recibido en la caja, entrega el cambio y el recibo. 13. El cliente se va con los productos comprados../.. continua 35

36 Plantilla TPV Extensiones síncronas #1. Si en 4 se introduce un código de producto inexistente el sistema genera un mensaje de error. #2. Si en 9 el cliente no tiene dinero suficiente la venta se cancela. Extensiones asíncronas Ninguna Si únicamente se desea mostrar la interacción con el sistema informático, debe eliminarse la referencia al cliente dentro de la descripción anterior. 36

37 Plantilla TPV (caso de uso sistema) Caso de uso Venta de Productos Actores Empleado (iniciador) Propósito Capturar una venta y su pago en efectivo Resumen Un cliente llega a la caja con productos para comprar. El empleado registra los productos y gestiona el pago en efectivo. Al acabar el cliente se va con los productos. Precondiciones El empleado se ha identificado en el sistema. Postcondiciones La venta se almacena en el sistema. Incluye - Extiende - Hereda de - 37

38 Plantilla TPV (caso de uso sistema) Intenciones de usuario Obligaciones del sistema 1. El empleado indica que 2. El sistema registra el comienza una nueva venta. inicio de una venta 3. Mientras queden artículos: El 4. El sistema determina el empleado introduce el código de precio del producto y añade cada producto y la cantidad la información a la cuenta. 5. El empleado indica el fin de la 6. El sistema calcula y venta muestra el total. 7. El empleado indica el dinero 8. El sistema calcula y que ha recibido muestra el cambio. Imprime un recibo y registra la venta. Extensiones síncronas #1. Si en 3 se introduce un código de producto inexistente i t el sistema genera un mensaje de error. #2. En 7 el empleado puede cancelar la venta. Extensiones asíncronas Ninguna 38

39 Estilos de descripción: casos esenciales y reales Los casos de uso esenciales son independientes de la interfaz y de la tecnología. Caso de uso esencial (descripción muy abstracta) Caso de uso real/concreto (descripción muy detallada) 39

40 Casos esenciales y concretos Acción de Usuario Insertar Tarjeta Introducir PIN Pulsar tecla Pulsar tecla Introducir cantidad Pulsar tecla Recoger tarjeta Recoger Dinero Intenciones de Usuario Identificarse Elegir Recoger dinero Respuesta del Sistema Leer cinta magnética Solicitar PIN Verificar PIN Presentar menú de operación Presentar r menú de cuenta Preguntar cantidad Hacer eco de cantidad Devolver tarjeta Dispensar dinero Obtener Efectivo, Caso de uso esencial Responsabilidades Sistema Verificar identidad Ofrecer elecciones de menú Entregar dinero 40

41 Escenarios y Casos de Uso Un escenario es una descripción textual de una interacción particular entre los actores y el sistema. A un caso de uso le corresponden varios escenarios. Los escenarios básicos o principales no contienen situaciones de error. Los secundarios describen situaciones de error o alternativas ti de ejecución. 41

42 Modelo estructurado Contiene los actores y las relaciones entre los casos de uso (explicado después) CommonUseCases:CoffeeMachine <<usecase>> MakeCoffee <<usecase>> MakeTea :Customer <<include>> <<usecase>> TeaMaking Ejemplo tomado de Telelogic Tau

43 Modelo estructurado (2) Ejemplo de UML

44 Relaciones entre actores y casos de uso. Herencia entre actores: La relación de herencia entre actores indica que el actor descendiente puede jugar todos los roles del actor antecesor. Cliente Bancario Actor antecesor Cliente Corporativo Cliente Normal Actor descendiente 44

45 Herencia entre actores Puede activar todos los casos de uso del actor antecesor. Actor abstracto: Participa en el modelo pero no interactúa directamente con el sistema. 45

46 Relaciones entre casos de uso: incluye Inclusión: Un caso de uso A incluye a un caso de uso B, si una instancia de A puede realizar todos los eventos que aparecen descritos en B. <<include>> Bus car Socio Bibliotecario Baja Socio (from Use Case View) La instanciación de Baja Socio utiliza siempre el flujo de eventos de Buscar Socio 46

47 Inclusión de casos de uso En la descripción de A se incluye una referencia a B. Flujo de eventos del caso de uso A Flujo de eventos del caso de uso B 47

48 Relación de extensión Un caso de uso B extiende a un caso de uso A, si en la descripción de A figura una condición cuyo cumplimiento origina la ejecución del flujo de eventos de B. Evaluar Solicitud de Crédito <<extend>> Solicitar Información adicional al cliente 48

49 Relación de extensión (2) Una extensión equivale a una inclusión + una condición. ió Descripción del caso de uso A Condición Descripción del caso de uso B 49

50 Relación de extensión (3) Útil para: Partes opcionales de un caso de uso. Representar sub-cursos de eventos que se ejecutan bajo ciertas condiciones. 50

51 Relación de herencia Un caso de uso B se dice que especializa a un caso de uso A si el flujo de eventos asociado a B es un refinamiento del flujo de eventos asociado a A. Relación similar a la herencia OO. Permite separar un patrón de interacción genérico (caso padre) de un patrón de interacción más específico (caso descendiente). 51

52 Herencia (2) Ejemplo Enviar solicitud crédito Enviar solicitud de crédito personal Enviar solicitud de crédito empresarial 52

53 Relaciones entre casos de uso (1) Dado un conjunto de casos de uso no existe una única forma de representar las relaciones entre ellos. Diferencias entre inclusión y extensión: Una inclusión es equivalente a una extensión sin condiciones. El caso incluido siempre forma parte del caso que incluye. El caso que incluye no tiene sentido sin el incluido. 53

54 Relaciones entre casos de uso (2) Diferencias extensión y especialización: La extensión se utiliza para representar alternativas de ejecución que se llevan a cabo en algunas ocasiones. La especialización se utiliza para representar patrones genéricos de interacción que pueden especializarse en patrones más específicos o concretos. Habitualmente la extensión ( delegación ) se puede formular en términos de especialización, y a la inversa. 54

55 Proceso de construcción del modelo de casos de uso Para construir el modelo de casos de uso: Técnica descendente. Técnica ascendente. Descendente Ascendente Detectar actores Encontrar Casos de uso Organizar modelo de Casos de uso Generalizar escenarios Detallar Casos de uso Crear escenarios 55

56 Reglas para identificar actores Los usuarios pueden jugar varios roles cuando interactúan con el sistema. Un usuario se puede corresponder con varios actores. 56

57 Reglas para detectar actores Cualquier grupo o individuo que caiga en alguna de las siguientes categorías: Quién usará el sistema? ste Quién instalará el mismo? Quién hará labores de mantenimiento? Quién lo apagará? Qué otros sistemas se comunicarán con éste? Quién obtiene información? Quién proporciona información? 57

58 Reglas para identificar casos de uso Prestando atención a los actores: Cuáles son las tareas que los actores quieren que el sistema realice para ellos?. Podrá un actor crear, almacenar, cambiar o borrar datos del sistema?. Será necesario que un actor informe al sistema sobre cambios que han ocurrido en el exterior del mismo?. Será necesario que el actor sea informado sobre ciertas ocurrencias o cambios dentro del sistema?. 58

59 Reglas... Las respuestas a cada una de las preguntas anteriores representan flujos de eventos que identifican casos de uso candidatos. 59

60 Documento de Requerimientos Puede emplearse el estándar [IEEE Std ]. Con la siguiente estructura, que debe ser instanciada para cada proyecto. 60

61 Documento de Requerimientos RUP sugiere la siguiente adaptación de la plantilla anterior. Tabla de Contenidos 1. Introducción igual que antes. 2. Descripción General igual que antes. 3. Requerimientos Específicos 3.1 Modelo de Casos de uso Cada caso de uso agrupado eventualmente por actor. Cada Caso de uso descrito mediante una plantilla textual. 3.2 Requerimientos adicionales Cubre atributos del sistema, restricciones de diseño, eficiencia. Apéndices Índice 61

62 Ejemplo Desarrollo de un software para procesar ordenes de pedido para una compañía de ventas por correo. Ésta se encarga de vender productos comprados a diversos proveedores. Dos veces por año, la compañía publica un catalogo con sus productos, el cual es enviado a sus clientes y aotraspersonas interesadas. Los clientes compran productos enviando una lista de los mismos con la forma de pago. La empresa completa la orden y envía el pedido a la dirección correspondiente del cliente. El software de procesamiento de pedidos debe ser capaz de efectuar un seguimiento completo de una orden desde que ésta es recibida hasta que ésta es enviada. Los clientes pueden devolver artículos. Una interfaz electrónica, como la Web, puede ser apropiada para algunos clientes. La compañía utilizará diversas compañías de envío para atender los pedidos.! NO se incluyen todos los requisitos!! 62

63 Ejemplo (2) Identificación de los límites del sistema. Actores humanos: Cliente, Representante Cliente, Empleado Ventas, etc. Otros sistemas: Sistema de contabilidad, control de inventario, etc. 63

64 Ejemplo (3) Introducir Pedido Obtener Estado Pedido Cliente Enviar Catálogo Representante Cliente Cancelar Pedido Devolver Artículo Obtener Información de Producto Actualizar Cantidades Producto Inventario Pedidos listos para enviar Imprimir Etiquetas Envío Compañia de envios Recepción de género Cargar en cuenta Calcular Gastos Envio Empleado Sistema de Contabilidad 64

65 Ejemplo (4) Caso de Uso: Introducir Pedido Descripción: El caso de uso se ejecuta cada vez que un cliente/representante desea solicitar un pedido. Actor iniciador: Representante o cliente (a través del web) Actores secundarios: (A completar) Precondiciones: El cliente está dado de alta en el sistema. Poscondiciones: El pedido se almacena, marcándose como pendiente de enviar. 65

66 Ejemplo (4) Intenciones del Usuario 1. El Cliente/Representante selecciona Nuevo Pedido 3. El c/r introduce el nombre y la dirección Respuesta del Sistema 2. El sistema pregunta el nombre y la dirección del cliente. 4. El s. comprueba que existe. 66

Índice. http://www.dicampus.es

Índice. http://www.dicampus.es Módulo 2 UML Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción:

Más detalles

TEMA 7: DIAGRAMAS EN UML

TEMA 7: DIAGRAMAS EN UML TEMA 7: DIAGRAMAS EN UML Diagramas en UML El bloque de construcción básico de UML es un Diagrama Introducción a UML 2 1 Modelo de Casos de Uso (MCU) Todos los casos de uso constituyen el MCU que describe

Más detalles

Los requisitos de un Sistema de Información

Los requisitos de un Sistema de Información Captura de requisitos Captura de Requisitos en el PUD Los requisitos de un Sistema de Información Modelo de Casos de Uso Otros instrumentos 1 Iteración en PUD Planificación de la Iteración Captura de requisitos:

Más detalles

DCU Diagramas de casos de uso

DCU Diagramas de casos de uso DCU Diagramas de casos de uso Universidad de Oviedo Departamento de Informática Contenidos Introducción Elementos básicos Más sobre los actores Más sobre los casos de uso Más sobre las asociaciones Otros

Más detalles

UML, ejemplo sencillo sobre Modelado de un Proyecto

UML, ejemplo sencillo sobre Modelado de un Proyecto UML, ejemplo sencillo sobre Modelado de un Proyecto Normal &DOLILFDU 0L3DQRUDPD 626 (VFULEHSDUD1RVRWURV Por Armando Canchala Contenido Introducción Objetivo Requerimientos Casos de Uso Subcasos de Uso

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Introducción a los casos de uso

Fundamentos de Ingeniería del Software. Capítulo 3. Análisis de Requisitos Introducción a los casos de uso Fundamentos de Ingeniería del Software Capítulo 3. Análisis de Requisitos Introducción a los casos de uso Cap 3. Análisis de Requisitos Estructura 1. Actividades iniciales. 2. Técnicas de recogida de la

Más detalles

UML. UML significa Lenguaje Unificado de Modelado UML combina lo mejor de:

UML. UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: UML UML significa Lenguaje Unificado de Modelado UML combina lo mejor de: Conceptos de modelado de datos (diagramas entidad-relación) Modelado de negocios (flujos de trabajo) Modelado de objetos Modelado

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS ANÁLISIS Y DISEÑO DE SISTEMAS Clase XVIII: Modelo Dinámico Diagramas de Actividades Primer Cuatrimestre 2013 Diagrama de Actividades (DA) Un grafo o diagrama de actividad (DA) es un tipo especial de máquina

Más detalles

PROCESO UNIFICADO CAPTURA DE REQUISITOS

PROCESO UNIFICADO CAPTURA DE REQUISITOS PROCESO UNIFICADO CAPTURA DE REQUISITOS El proceso unificado de desarrollo, Ivar Jacobson, Grady Booch, James Rumbaugh, Ed. Addison Wesley, 1999 The unified software development process, Ivar Jacobson,

Más detalles

Instructivo para la elaboración de un Manual Técnico

Instructivo para la elaboración de un Manual Técnico Instructivo para la elaboración de un Manual Técnico Autora: Ing. Alena González Reyes. (agonzalez@ceis.cujae.edu.cu) Ciudad de la Habana, Cuba Marzo, 2010 Índice 1. Introducción... 3 2. Confección...

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

13019 Diseño de bases de datos

13019 Diseño de bases de datos 13019 Diseño de bases de datos Diseño de requisitos mediante casos de uso Wladimiro Díaz Wladimiro.Diaz@uv.es Universitat de València 13019 Diseño de bases de datos p. 1 Introducción En literatura, un

Más detalles

Diagramas de Casos de Uso

Diagramas de Casos de Uso Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja actualmente, o de cómo se desea que trabaje. No pertenece realmente al enfoque orientado a objeto, más bien es

Más detalles

Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT

Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT Proyecto de Fin de Carrera Universidad Politécnica de Valencia Escuela Técnica Superior de Informática Desarrollo de un Sistema de Gestión de Proyectos mediante el framework GWT Realizado por: Dirigido

Más detalles

Casos de Uso Diagramas de Casos de Uso. Universidad de los Andes Demián Gutierrez Abril 2011 1

Casos de Uso Diagramas de Casos de Uso. Universidad de los Andes Demián Gutierrez Abril 2011 1 Casos de Uso Diagramas de Casos de Uso Universidad de los Andes Demián Gutierrez Abril 2011 1 Casos de Uso ( Qué es un caso de uso?) Caso de Uso? 2 Casos de Uso ( Qué es un caso de uso?) Un caso de uso

Más detalles

Ingeniería Software software. Análisis de requisitos y especificación de una aplicación

Ingeniería Software software. Análisis de requisitos y especificación de una aplicación Ingeniería Software software 4º Físicas 4º de Físicas Análisis de requisitos y especificación de una aplicación José M. Drake Computadores y Tiempo Real Santander, 1 Ingeniería de Programación (4º Físicas)

Más detalles

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO

Ejercicio Guiado de Análisis y Diseño Orientado a Objetos. Ejemplo: CAJERO AUTOMÁTICO Ejercicio Guiado de Análisis y Diseño Orientado a Objetos Ejemplo: CAJERO AUTOMÁTICO El siguiente ejercicio muestra las diferentes actividades que se realizan dentro del desarrollo de un producto software

Más detalles

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases

Diagramas del UML. A continuación se describirán los diagramas más comunes del UML y los conceptos que representan: Diagrama de Clases El UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Debido a que el UML es un lenguaje, cuenta con reglas para combinar tales elementos. La finalidad de los

Más detalles

CAPITULO 2. Como se definió en el plan del presente proyecto, este será desarrollado bajo

CAPITULO 2. Como se definió en el plan del presente proyecto, este será desarrollado bajo 1 CAPITULO 2 ANÁLISIS DEL SISTEMA 1. Introducción Como se definió en el plan del presente proyecto, este será desarrollado bajo la metodología orientada a objetos. El objetivo del análisis será marcar

Más detalles

Introducción al UML. Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación

Introducción al UML. Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación Introducción al UML Domingo Hernández H. Escuela de Ingeniería de Sistemas Departamento de computación Contenido Qué es UML?. Diagramas Utilizados en UML. Ejemplos. Qué es UML UML es un Lenguaje de Modelado

Más detalles

GLOSARIO DE TÉRMINOS. Proyecto Fin de Carrera Memoria. Ingeniería Técnica de Informática de Gestión

GLOSARIO DE TÉRMINOS. Proyecto Fin de Carrera Memoria. Ingeniería Técnica de Informática de Gestión Ingeniería Técnica de Informática de Gestión GLOSARIO DE TÉRMINOS Proyecto Fin de Carrera Memoria Benjamín Pérez Blaya Estudiante Jairo Sarrias Guzmán Consultor Pamplona / 19-12-2011 Índice Definición,

Más detalles

Modelo alternativo de análisis: Modelo de Jacobson

Modelo alternativo de análisis: Modelo de Jacobson Modelo alternativo de análisis: Modelo de Jacobson! Modelo de análisis de Jacobson o análisis de la robustez ( Robustness Analysis )! Es un nivel de diseño intermedio entre la etapa de Captura de requerimientos

Más detalles

TEST (8 preguntas, 0 4 puntos por pregunta correcta, -0 15 puntos por error) [Marcar sólo una opción]

TEST (8 preguntas, 0 4 puntos por pregunta correcta, -0 15 puntos por error) [Marcar sólo una opción] EXAMEN PARCIAL 2 Temas 7-13 TEST (8 preguntas, 0 4 puntos por pregunta correcta, -0 15 puntos por error) [Marcar sólo una opción] 1. Cuál de las siguientes vistas arquitecturales NO forma parte de las

Más detalles

Ejemplo de Análisis Orientado a Objetos ATMs

Ejemplo de Análisis Orientado a Objetos ATMs Ejemplo de Análisis Orientado a Objetos ATMs Se desea diseñar el software necesario para una red bancaria provista de cajeros automáticos (ATMs), que serán compartidos por un consorcio de bancos. Cada

Más detalles

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos

Estructura de clases. Estructura de Objetos. Arquitectura de módulos. Arquitectura de procesos 3.3 EL MÉTODO DE BOOCH. 3.3. Introducción. El método cuenta con una notación expresiva y bien definida que le permite al diseñador comunicar sus ideas y concentrarse en problemas más serios. Para la captura

Más detalles

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los

Más detalles

Diseño de Sistemas Universidad CAECE Año 2005

Diseño de Sistemas Universidad CAECE Año 2005 Diseño de Sistemas Universidad CAECE Año 2005 Introducción El siguiente ejemplo muestra la aplicación del proceso de desarrollo de software según Ivar Jacobson. En muchos de los pasos el método ha sido

Más detalles

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reutilizable Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Objetivos Para explicar los beneficios del software reutilizable y algunos de sus problemas Para discutir

Más detalles

Proceso Unificado de Rational

Proceso Unificado de Rational RUP: El Proceso Unificado de Rational XP: Programacion Extrema EAP: Computación Científica Ciencia de la Computación V Prof. Oscar Brnito Pacheco Proceso Unificado de Rational Orígenes Modelo original

Más detalles

INGENIERÍA DEL SOFTWARE I Tema 8. Contexto y Requisitos del Sistema (en desarrollo OO)

INGENIERÍA DEL SOFTWARE I Tema 8. Contexto y Requisitos del Sistema (en desarrollo OO) INGENIERÍA DEL SOFTWARE I Tema 8 Contexto y Requisitos del Sistema (en desarrollo OO) Univ. Cantabria Fac. de Ciencias Francisco Ruiz y Patricia López Objetivos del Tema Conocer en detalle la técnica de

Más detalles

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño

Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño Unidad II: Diseño de Bases de Datos y el modelo E-R. 2.1 El Proceso de Diseño El proceso de diseño para una base de datos consta básicamente de 7 pasos, los cuáles se describen en la siguiente imagen.

Más detalles

Capítulo 2: Análisis de Módulos CAPÍTULO 2 ANÁLISIS DE MÓDULOS PROCESOS DEL SISTEMA LMP Y TARJETA BEC Después de conocer los requerimientos para el desarrollo del sistema LMP, de definir con que herramientas

Más detalles

ESTIMACIÓN DE PROYECTOS DE SOFTWARE CON PUNTOS DE CASOS DE USO

ESTIMACIÓN DE PROYECTOS DE SOFTWARE CON PUNTOS DE CASOS DE USO ESTIMACIÓN DE PROYECTOS DE SOFTWARE CON PUNTOS DE CASOS DE USO Valero Orea, Sergio* RESUMEN Uno de los principales problemas a los que nos enfrentamos los desarrolladores de software al momento de planear

Más detalles

Tema 4d: Proceso Unificado: Captura de Requisitos

Tema 4d: Proceso Unificado: Captura de Requisitos Tema 4d: Proceso Unificado: Captura de Requisitos Marcos López Sanz Índice Visión general Diagramas UML Proceso de captura de requisitos Enumerar requisitos candidatos Comprender el contexto del sistema

Más detalles

Documento de Arquitectura de Software IEEE-1471-2000

Documento de Arquitectura de Software IEEE-1471-2000 Documento de Arquitectura de Software Control del documento IEEE-1471-2000 Proyecto Sistema Restaurant Título Arquitectura del Sistema [v1.0 al 02 de Julio de 2009] Generado por Magister en Informática

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

Modelado Avanzado con Casos de Uso. Diseño de Software Avanzado Departamento de Informática

Modelado Avanzado con Casos de Uso. Diseño de Software Avanzado Departamento de Informática Modelado Avanzado con Casos de Uso Especificación Gráfica de Casos de Uso Una simple secuencia de acciones no puede describir adecuadamente la riqueza de situaciones que se pueden presentar en un caso

Más detalles

La importancia del desarrollo para el buen diseño del software

La importancia del desarrollo para el buen diseño del software La importancia del desarrollo para el buen diseño del software RESUMEN N L González Morales. 1 En este ensayo se examinan los temas vistos en clase que son Desarrollo de Orientado a Objetos y Arquitectura

Más detalles

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV

Evaluar el rendimiento de los servicios de comunicaciones. ANEXO CLIV 746 Miércoles 5 octubre 2005 Suplemento del BOE núm. 238 CE2.1 Identificar los distintos sistemas de archivo utilizables en un dispositivo de almacenamiento dado para optimizar los procesos de registro

Más detalles

1.INTRODUCCIÓN... 6 2.INICIAR EXECUTER POS... 7 3.GENERALIDADES... 10 4.VENTAS...

1.INTRODUCCIÓN... 6 2.INICIAR EXECUTER POS... 7 3.GENERALIDADES... 10 4.VENTAS... Tabla de Contenido 1.INTRODUCCIÓN... 6 2.INICIAR EXECUTER POS... 7 3.GENERALIDADES... 10 4.VENTAS... 15 4.1 AGREGAR ARTÍCULO... 15 4.2 ELIMINAR ARTÍCULO... 19 4.3 DEFINIR CANTIDAD POR ARTÍCULO... 21 4.4

Más detalles

Ingeniería de Software Calidad de Procesos y Productos de Software

Ingeniería de Software Calidad de Procesos y Productos de Software Ingeniería de Software Calidad de Procesos y Productos de Software M. Visconti & H. Astudillo Departamento de Informática Universidad Técnica Federico Santa María Calidad

Más detalles

Comentarios de introducción al Procedimiento de Compras Como apuntábamos en los capítulos iniciales, uno de los pilares en los que se apoya nuestro sistema de la calidad es el producto entregado a nuestros

Más detalles

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Visión. Versión 3.0

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Visión. Versión 3.0 Deportes LSI 03 Sistema para Gestión de Artículos Deportivos LSI 03 Visión Versión 3.0 Historial de Revisiones Fecha Versión Autor 22/10/2002 0.9 Propuesta inicial del documento Visión con las primeras

Más detalles

Departamento de Informática Segundo semestre de 2011. Repaso para Certamen 1

Departamento de Informática Segundo semestre de 2011. Repaso para Certamen 1 Universidad Técnica Federico Santa María ILI-236 Fundamentos de Ing. de SW Departamento de Informática Segundo semestre de 2011 Caso: Sistema de control de cajeros Repaso para Certamen 1 Su compania ha

Más detalles

SISTEMA DE GESTIÓN DE BASE DE DATOS (Database Management System (DBMS))

SISTEMA DE GESTIÓN DE BASE DE DATOS (Database Management System (DBMS)) SISTEMA DE GESTIÓN DE BASE DE DATOS (Database Management System (DBMS)) Los sistemas de gestión de bases de datos son un tipo de software muy específico, dedicado a servir de interfaz entre la base de

Más detalles

Etapa de Diseño: Gestión de Hotel Diseño de Sistemas Software

Etapa de Diseño: Gestión de Hotel Diseño de Sistemas Software Etapa de Diseño: Gestión de Hotel Diseño de Sistemas Software Antonio Falcón Aragón José Luis Falcón Ramírez Carlos Villegas Nuñez 15 de marzo de 2010 1 Índice 1. Diseño de la Aplicación 3 1.1. Diagrama

Más detalles

ADMINISTRACIÓN DE BASES DE DATOS DISTRIBUIDAS

ADMINISTRACIÓN DE BASES DE DATOS DISTRIBUIDAS 5 ADMINISTRACIÓN DE BASES DE DATOS DISTRIBUIDAS Contenido: 5.1 Conceptos Generales Administración de Bases de Datos Distribuidas 5.1.1 Administración la Estructura de la Base de Datos 5.1.2 Administración

Más detalles

EJERCICIOS TEMA 3: MANIPULACIÓN DE PEDIDOS

EJERCICIOS TEMA 3: MANIPULACIÓN DE PEDIDOS EJERCICIOS TEMA 3: MANIPULACIÓN DE PEDIDOS 1- MANPULACIÓN Y CONSERVACIÓN DE PRODUCTOS 1.1- PERSONAL AL SERVICIO DEL ALMACÉN 1) Qué cuatro categorías profesionales podemos distinguir entre el personal de

Más detalles

Curso Taller de Arquitectura de Software usando UML

Curso Taller de Arquitectura de Software usando UML Curso Taller de Arquitectura de Software usando UML Presentación: Este curso comprende las técnicas necesarias para el modelamiento de sistemas a través de los diagramas definidos por UML (Unified Modelling

Más detalles

Capítulo 5 Implementación de Gisweb

Capítulo 5 Implementación de Gisweb Capítulo 5 Implementación de Gisweb [5. Implementación de Gisweb] En este capítulo veremos como se hizo una implementación propia de un Web Feature Service a partir del diseño obtenido mediante el proceso

Más detalles

Los procesos de negocio están en todas partes, en cada organización, en cada nivel.

Los procesos de negocio están en todas partes, en cada organización, en cada nivel. Qué es BPM? Los procesos de negocio están en todas partes, en cada organización, en cada nivel. La automatización y racionalización de procesos específicos pueden disminuir los costos y mejorar la calidad.

Más detalles

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a

COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a 5. METODOLOGIAS COBIT o COBIT enfatiza el cumplimiento regulatorio, ayuda a las organizaciones a incrementar su valor a través de las tecnologías, y permite su alineamiento con los objetivos del negocio

Más detalles

Ejercicios Diagramas de casos de uso

Ejercicios Diagramas de casos de uso Ejercicios Diagramas de casos de uso Ejercicio 1. Para cada una de las siguientes afirmaciones indicar si es Verdadera o Falsa. Los actores de un sistema representan, en particular, personas (mas precisamente

Más detalles

Conceptos de redes. LAN (Local Area Network) WAN (Wide Area Network)

Conceptos de redes. LAN (Local Area Network) WAN (Wide Area Network) Conceptos de redes. Una red de ordenadores permite conectar a los mismos con la finalidad de compartir recursos e información. Hablando en términos de networking, lo importante es que todos los dispositivos

Más detalles

Tema 5. Diseño detallado.

Tema 5. Diseño detallado. Ingeniería del Software II 2011 Tema 5. Diseño detallado. Diseño del Software. Los requisitos y el análisis orientado a objetos se centran en aprender a hacer lo correcto: Entender los objetos de nuestro

Más detalles

ACUEDUCTOS VEREDALES

ACUEDUCTOS VEREDALES ACUEDUCTOS VEREDALES SOFTWARE PARA FACTURACIÓN DEL SERVICIO DE ACUEDUCTO PROPUESTA TÉCNICO ECONÓMICA Wilmer García Socio - Director TI Móvil: (57) 300.560.79.73 Skype: wilmer.gl wilmer.garcia@solucionessig.com

Más detalles

Documento de Arquitectura de Software. KunaySoft. Autores: Juan Camilo González Vargas. Javier Leonardo Parra Laguna

Documento de Arquitectura de Software. KunaySoft. Autores: Juan Camilo González Vargas. Javier Leonardo Parra Laguna Documento de Arquitectura de Software KunaySoft Autores: Juan Camilo González Vargas Javier Leonardo Parra Laguna Pontificia Universidad Javeriana Bogotá, Colombia Noviembre 2014 Tabla de contenido 1.

Más detalles

Evaluación del Software

Evaluación del Software Evaluación del Software Evaluación de Software El avance informático actual es muy alto comparado con lo se tenía en los años 90, al hablar de desarrollo de software se hace más notable, en el hecho por

Más detalles

PROCEDIMIENTOS DEL SISTEMA INTEGRAL DE TIENDAS Y FARMACIAS TOMO 6 PARTE 4

PROCEDIMIENTOS DEL SISTEMA INTEGRAL DE TIENDAS Y FARMACIAS TOMO 6 PARTE 4 Normateca Electrónica Institucional NORMATECA ELECTRÓNICA INSTITUCIONAL MANUAL DE DEL TOMO 6 PARTE 4 INSTITUTO DE SEGURIDAD Y SERVICIOS SOCIALES DE LOS TRABAJADORES DEL ESTADO SUPERISSSTE FICHA TÉCNICA

Más detalles

STOCK CONTROL CENTER Edicion BASICA

STOCK CONTROL CENTER Edicion BASICA STOCK CONTROL CENTER Edicion BASICA SCC Básico, sistema con un equilibrio entre costo y prestaciones, su bajo costo y su simplicidad hace de esta herramienta útil para el control de stock, y ventas. Con

Más detalles

DIAGRAMA DE CLASES EN UML

DIAGRAMA DE CLASES EN UML DIAGRAMA DE CLASES EN UML Mg. Juan José Flores Cueto jflores@usmp.edu.pe Ing. Carmen Bertolotti Zuñiga cbertolotti@usmp.edu.pe INTRODUCCIÓN UML (Unified Modeling Language) es un lenguaje que permite modelar,

Más detalles

BASES DE DATOS TEMA 1

BASES DE DATOS TEMA 1 BASES DE DATOS TEMA 1 Contenido 1. Qué es una base de datos? 2. Un ejemplo 3. Personas que interactúan con la base de datos 4. Inconvenientes de los sistemas de ficheros 5. Modelos de datos 6. Lenguajes

Más detalles

Manual de Procedimientos Punto de Venta -SmartBIT POS-

Manual de Procedimientos Punto de Venta -SmartBIT POS- Manual de Procedimientos Punto de Venta -SmartBIT POS- CONTENIDO CONTENIDO PAGINA I. CAJA 1. Asignación de caja y resoluciones 2 2. Abrir Caja 3 3. Flujo de Caja 4 4. Cierre de caja 5 II. MOVIMIENTOS DE

Más detalles

DOCUMENTO DE REQUISITOS Subsistema de Reservas del Sistema de Gestión Hotelera

DOCUMENTO DE REQUISITOS Subsistema de Reservas del Sistema de Gestión Hotelera DOCUMENTO DE REQUISITOS Subsistema de Reservas del Sistema de Gestión Hotelera IN77J - Orientación a Objetos para e-business Daniel Perovich Andrés Vignaga {dperovic, avignaga}@dcc.uchile.cl Magíster en

Más detalles

DOCUMENTO VISIÓN SISTEMA DE VENTAS Y PRÉSTAMOS DE LA CINEMATECA BOLIVIANA PAWI. Versión 1.0. Aruquipa Mamani Rolando Willy

DOCUMENTO VISIÓN SISTEMA DE VENTAS Y PRÉSTAMOS DE LA CINEMATECA BOLIVIANA PAWI. Versión 1.0. Aruquipa Mamani Rolando Willy DOCUMENTO VISIÓN SISTEMA DE VENTAS Y PRÉSTAMOS DE LA CINEMATECA BOLIVIANA PAWI Versión 1.0 Integrantes: Aruquipa Mamani Rolando Willy Layme Ordoñez Roxana Paola Módulos Venta de Material y Facturación

Más detalles

Codex.pro. Preinscripción y matriculación

Codex.pro. Preinscripción y matriculación Codex.pro. Preinscripción y matriculación Índice Codex.pro. Preinscripción y matriculación...1 1. Introducción...2 2. Pruebas de acceso...3 2.1. Configuración de los procesos asociados...3 2.2. Datos del

Más detalles

Capítulo 4. Diseño de un sistema para reconocimiento y consulta de las tarjetas Hu

Capítulo 4. Diseño de un sistema para reconocimiento y consulta de las tarjetas Hu Capítulo 4. Diseño de un sistema para reconocimiento y consulta de las tarjetas Hu En este capítulo se describe el diseño de un sistema, denominado HuSystem, planteado para cumplir dos objetivos: Búsqueda

Más detalles

Dell Premier. Guía para comprar y efectuar pedidos de. Registro en la página Premier. Administrar su perfil personal

Dell Premier. Guía para comprar y efectuar pedidos de. Registro en la página Premier. Administrar su perfil personal Guía para comprar y efectuar pedidos de Dell Premier Dell Premier es su una solución Online personalizada y segura en el que puede llevar a cabo un proceso de compras fácil, económico y eficaz. Revise

Más detalles

N & D RECEPCIONES. Taller de Análisis y Diseño de Sistemas. Estela Caballero Casco

N & D RECEPCIONES. Taller de Análisis y Diseño de Sistemas. Estela Caballero Casco N & D RECEPCIONES Taller de Análisis y Diseño de Sistemas Estela Caballero Casco Orientador: Lic. Jorge Adalberto Arevalos Caaguazú Paraguay Junio, 2012 1 Fecha Versión Descripción de cambios Autor 27/02/2012

Más detalles

Ingeniería del Software I 1er. Cuatrimestre 2006

Ingeniería del Software I 1er. Cuatrimestre 2006 - 1 - Ingeniería del Software I 1er. Cuatrimestre 2006 Proyecto: PromoToto Informe 1: Análisis de Requerimientos y especificación Base para el Trabajo Práctico de Testing - 2 - Índice 1 Introducción...

Más detalles

ANÁLISIS DE REQUISITOS

ANÁLISIS DE REQUISITOS ANÁLISIS DE REQUISITOS 3.1.- INTRODUCCIÓN AL ANALISIS DE REQUISITOS Como se dijo en capítulos anteriores, el término análisis aplicado a sistemas significa descomponer el sistema en sus componentes para

Más detalles

Guía del Curso Analista Programador PHP Javascript

Guía del Curso Analista Programador PHP Javascript Guía del Curso Analista Programador PHP Javascript Modalidad de realización del curso: Número de Horas: Titulación: Online 180 Horas Diploma acreditativo con las horas del curso OBJETIVOS UML usa técnicas

Más detalles

6.4 Actores y casos de uso para el sistema de reservaciones de vuelos

6.4 Actores y casos de uso para el sistema de reservaciones de vuelos jen la vision logica del sistema, debiendo haber consistencia entre la imagen conceptual del usuario y el comportamiento real del sistema. Si las interfaces son protocolos de hardware, se pueden referir

Más detalles

Norma Internacional ISO 9001:2008: Sistemas de Gestión de la Calidad- Requisitos. 4. Sistema de Gestión de la Calidad

Norma Internacional ISO 9001:2008: Sistemas de Gestión de la Calidad- Requisitos. 4. Sistema de Gestión de la Calidad Norma Internacional ISO 9001:2008: Sistemas de Gestión de la Calidad- Requisitos 4. Sistema de Gestión de la Calidad Figura N 1. Estructura del capítulo 4, Norma ISO 9001:2008. La Norma ISO 9001: 2008

Más detalles

Política de Privacidad por Internet

Política de Privacidad por Internet Política de Privacidad por Internet Última actualización: 17 de noviembre de 2013 Su privacidad es importante para nosotros. Esta Política de Privacidad por Internet explica cómo recopilamos, compartimos,

Más detalles

SISTEMA ETAP en línea Estándares Tecnológicos para la Administración Pública

SISTEMA ETAP en línea Estándares Tecnológicos para la Administración Pública JEFATURA DE GABINETE DE MINISTROS SISTEMA ETAP en línea Estándares Tecnológicos para la Administración Pública Manual para los Organismos Índice Índice... 2 Descripción... 3 Cómo solicitar la intervención

Más detalles

FACULTAD DE INGENIERÍA MECÁNICA Y ELÉCTRICA INGENIERÍA DE SOFTWARE Profr. Víctor Castillo. PRÁCTICA No. 2 Prototipos formales de software

FACULTAD DE INGENIERÍA MECÁNICA Y ELÉCTRICA INGENIERÍA DE SOFTWARE Profr. Víctor Castillo. PRÁCTICA No. 2 Prototipos formales de software FACULTAD DE INGENIERÍA MECÁNICA Y ELÉCTRICA INGENIERÍA DE SOFTWARE Profr. Víctor Castillo PRÁCTICA No. 2 Prototipos formales de software ALUMNO: GRUPO: Introducción El desarrollo de un artefacto de software

Más detalles

Análisis de Requisitos

Análisis de Requisitos Análisis de Requisitos Los requisitos determinan lo que hará el sistema y definen restricciones sobre su operación e implementación. El análisis de requisitos es el proceso del estudio de las necesidades

Más detalles

Manual de usuario para Android de la aplicación PORTAFIRMAS MÓVIL

Manual de usuario para Android de la aplicación PORTAFIRMAS MÓVIL Manual de usuario para Android de la aplicación PORTAFIRMAS MÓVIL Índice 1 Introducción... 5 1.1 Perfil de la aplicación... 5 1.2 Requisitos técnicos... 5 2 Manual de usuario... 7 2.1 Instalación del certificado...

Más detalles

Procedimiento para el Monitoreo y Control de Tecnologías de Información

Procedimiento para el Monitoreo y Control de Tecnologías de Información Procedimiento para el Monitoreo y Control de Tecnologías de Información DIRECCIÓN DE COORDINACIÓN TÉCNICA Y PLANEACIÓN DICIEMBRE DE 2009 PR-DCTYP-15 Índice 1. INTRODUCCIÓN.... 3 2. OBJETIVO.... 3 3. ALCANCE....

Más detalles

TPVplus Élite es la solución ideal para gestionar y optimizar las operaciones comerciales de los puntos de venta.

TPVplus Élite es la solución ideal para gestionar y optimizar las operaciones comerciales de los puntos de venta. TPVplus Élite La solución de gestión de punto de venta multipuesto ideal para trabajar en redes locales o en ubicaciones remotas gracias a su completa funcionalidad. TPVplus Élite es la solución ideal

Más detalles

Procedimiento del sistema integrado de gestión. Compras y control de proveedores

Procedimiento del sistema integrado de gestión. Compras y control de proveedores GESTIÓN DE LA CALIDAD Procedimiento del sistema integrado de gestión. Compras y control de proveedores Luis Francisco Rubio Cerezo Asesor en Implantación de Sistemas de Calidad rubiocerezo@telefonica.net

Más detalles

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles

Información general. Gestión de proyectos. Facturación. Interfaces

Información general. Gestión de proyectos. Facturación. Interfaces ESP Información general El sistema de logística avanzada (ALS) es un innovador sistema de información logística para la gestión, planificación y el seguimiento de los procesos empresariales en terminales

Más detalles

Manual de BABEL EN EUROWIN

Manual de BABEL EN EUROWIN Manual de BABEL EN EUROWIN Documento: me_babel Edición: 03 Nombre: Manual de Babel en Eurowin Fecha: 02-05-2012 Tabla de contenidos 1. Introducción... 4 1.1. Compatibilidades... 4 1.2. Requisitos... 5

Más detalles

El Proceso Unificado Rational para el Desarrollo de Software.

El Proceso Unificado Rational para el Desarrollo de Software. Instituto de Electrónica y Computación El Proceso Unificado Rational para el Desarrollo de Software. Carlos Alberto Fernández y Fernández Huajuapan de León, Oaxaca 26 de octubre de 2000 Objetivo Proporcionar

Más detalles

GLOSARIO DE CONCEPTOS A NIVEL FINANCIERO PARA CONOCIMIENTO GENERAL

GLOSARIO DE CONCEPTOS A NIVEL FINANCIERO PARA CONOCIMIENTO GENERAL GLOSARIO DE CONCEPTOS A NIVEL FINANCIERO PARA CONOCIMIENTO GENERAL A Activos financieros: son aquellos cuyo precio depende de las rentas que se suponen generaran en el futuro. Activos reales: son aquellos

Más detalles

OPTIMIZACIÓN PROCESOS ADMINISTRATIVOS DE TALLERES MECÁNICOS. OPAM.

OPTIMIZACIÓN PROCESOS ADMINISTRATIVOS DE TALLERES MECÁNICOS. OPAM. OPTIMIZACIÓN PROCESOS ADMINISTRATIVOS DE TALLERES MECÁNICOS. OPAM. DAVID ENRIQUE ISAZA CARDENAS OSCAR IVÁN MORENO GONZÁLEZ CORPORACIÓN UNIVERSITARIA MINUTO DE DIOS FACULTAD DE INGENIERÍA DEPARTAMENTO DE

Más detalles

SOMI XVIII Congreso de Instrumentación TECNOLOGIAS DE LA INFORMACION BSR18171

SOMI XVIII Congreso de Instrumentación TECNOLOGIAS DE LA INFORMACION BSR18171 SOFTWARE DE CAJERO AUTOMÁTICO UTILIZANDO PROGRAMACIÓN CONCURRENTE Y PARALELA Bárbara Emma Sánchez Rinza y María Lucero Aranda Ortiz. Benemérita Universidad Autónoma de Puebla edifico 135 14 sur y Av. San

Más detalles

TALLER No. 1 Capitulo 1: Conceptos Básicos de Bases de datos

TALLER No. 1 Capitulo 1: Conceptos Básicos de Bases de datos TALLER No. 1 Capitulo 1: Conceptos Básicos de Bases de datos 1. La base de datos se puede considerar como una unificación de varios archivos de datos independientes, cuyo propósito básico es evitar la

Más detalles

Métricas. Valentin Laime. Calidad de Software

Métricas. Valentin Laime. Calidad de Software Calidad de Software: Métricas Valentin Laime Calidad de Software 10/29/2014 1 Métricas Que miden Beneficios Medidas Productividad Calidad Futuras Estimaciones Directas Indirectas Defecto/fallo Vs. Error

Más detalles

Diagramas de Clase en UML 1.1

Diagramas de Clase en UML 1.1 Diagramas de Clase en UML. Francisco José García Peñalvo Licenciado en Informática. Profesor del Área de Lenguajes y Sistemas Informáticos de la Universidad de Burgos. fgarcia@.ubu.es Carlos Pardo Aguilar

Más detalles

INGENIERÍA DEL SOFTWARE I Tema 5 Contexto y Requisitos del Sistema (Modelado en desarrollo OO)

INGENIERÍA DEL SOFTWARE I Tema 5 Contexto y Requisitos del Sistema (Modelado en desarrollo OO) INGENIERÍA DEL SOFTWARE I Tema 5 Contexto y Requisitos del Sistema (Modelado en desarrollo OO) Universidad de Cantabria Facultad de Ciencias Patricia López y Francisco Ruiz Objetivos del Tema Objetivos:

Más detalles

14. DESARROLLO VERSUS COMPRA DE LA SOLUCIÓN COMPUTACIONAL

14. DESARROLLO VERSUS COMPRA DE LA SOLUCIÓN COMPUTACIONAL 226 14. DESARROLLO VERSUS COMPRA DE LA SOLUCIÓN COMPUTACIONAL Como se planteó en el capítulo anterior, entre las opciones para disponer de una solución computacional están: la compra de una solución ya

Más detalles

así como actividades de análisis de ventas. Combinadas estas capacidades ayudan a mejorar la respuesta al cliente.

así como actividades de análisis de ventas. Combinadas estas capacidades ayudan a mejorar la respuesta al cliente. Presentación. SIP Manufacturing es un sistema integrado de MRP II basado en Windows para la administración de ventas, producción y finanzas en un ambiente de manufactura. SIP Manufacturing proporciona

Más detalles

Especificación de Requisitos según el estándar de IEEE 830

Especificación de Requisitos según el estándar de IEEE 830 Especificación de Requisitos según el estándar de IEEE 830 IEEE Std. 830-1998 22 de Octubre de 2008 Resumen Este documento presenta, en castellano, el formato de Especificación de Requisitos Software (ERS)

Más detalles

Documentando la arquitectura de software Principios básicos por Omar Gómez

Documentando la arquitectura de software Principios básicos por Omar Gómez Documentando la arquitectura de software Principios básicos por Omar Gómez En la actualidad, uno de los temas candentes que se habla dentro de la comunidad de desarrollo de software es el referente a las

Más detalles

CAPÍTULO I. Sistemas de Control Distribuido (SCD).

CAPÍTULO I. Sistemas de Control Distribuido (SCD). 1.1 Sistemas de Control. Un sistema es un ente cuya función es la de recibir acciones externas llamadas variables de entrada que a su vez provocan una o varias reacciones como respuesta llamadas variables

Más detalles

CAPITULO 2. 2 Manual de Servicio al Cliente 8

CAPITULO 2. 2 Manual de Servicio al Cliente 8 CAPITULO 2 2 Manual de Servicio al Cliente 8 Un Manual de Servicio al cliente es la elaboración de un plan que garantice satisfacer las necesidades concretas de los clientes de la empresa tanto actuales

Más detalles

2 Motivación. 2.1 Problemas en la Utilización de los Casos de Uso

2 Motivación. 2.1 Problemas en la Utilización de los Casos de Uso El Modelo del Negocio como base del Modelo de Requisitos 1 María José Ortín, Jesús García Molina, Begoña Moros, Joaquín Nicolás Grupo de Investigación de Ingeniería del Software Departamento de Informática

Más detalles