Modelado con Casos de Uso (CU)

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

Download "Modelado con Casos de Uso (CU)"

Transcripción

1 Universidad de Congreso Modelado con Casos de Uso (CU) Análisis de Sistemas 2do año Qué es el modelado de Casos de uso? Una forma de capturar el comportamiento deseado del sistema a desarrollar Una manera de comunicar ese comportamiento Identificar quién y qué interactúa con el sistema Describir lo que el sistema debe hacer para esos actores Un manera de verificar que se hayan capturado todos los requerimientos. Una herramienta que permite planificar. 1

2 Para quiénes están dirigidos? Equipo del Cliente Cliente Usuario Equipo de Desarrollo Documentador Analista Administrador de Proyectos Tester Diseñador Para quiénes están dirigidos? Los CU son leidos por varios stakeholders. Ellos proveen una forma de describir el problema de manera que todos lo entiendan. El modelo debería ser comprensible para personas dentro de la organización (analistas, desarrolladores, implementadores, testers) y para personas externas (clientes y usuarios) Dado que los CU son especificados desde las perspectivas del usuario, el modelo de casos de uso es ideal para comunicar al cliente y usuario, la funcionalidad y comportamiento del sistema propuesto. 2

3 Beneficios de los casos de uso Brindan un contexto para los requerimientos Son fáciles de entender. Ayudan a conseguir el acuerdo con el cliente. Reflejan porque es necesario el sistema Caso Uso: Para que es usado el sistema. Actor: Quién/Qué desean interactuar con el sistema. El modelo es el medio de comunicación entre el cliente y el equipo de desarrollo y de asegurar que se va a construir lo que él cliente quiere Actores y Casos de Uso actor caso de uso Lo que el actor quiere que el sistema haga, cuando lo usa Algo/ Alguien externo al sistema que interactúa con el sistema. 3

4 Definición de Caso de Uso Seleccionar Producto Un caso de uso describe una secuencia de acciones ejecutadas por el sistema que proporciona un resultado de valor para un actor Recorriendo la definición de Caso de Uso Un CU describe un conjunto de prosibles ejecuciones del sistema. Describe un flujo a través del sistema hasta conseguir un resultado de valor para un actor. Secuencia de acciones Conjunto de actividades y decisiones que suceden producto de la interacción entre el actor y el sistema Ejecutadas por un sistema las acciones ejecutadas por el sistema son los requerimientos funcionales (es el reflejo de cómo se comporta el sistema) Resultado de valor El CU termina con un valor para alguien/algo. Para un actor Puede suceder que un CU brinde valor a más de un actor, en ese caso estamos en presencia de un CU grande lo aconsejable, para lograr el entedimiento justo y eliminar la ambigüedad, es quebrar el CU en los que sea necesario 4

5 Quiénes son los Actores? María actúa como Help-desk Juan actúa como Help-desk Otro Software X actua como Help-desk HelpDesk Canalizar solicitud Quiénes son los Actores? Teniendo en cuenta el ejemplo anterior Muchos usuarios pueden juagar un mismo rol, lo cual significa que ellos son todos instancias de un mismo actor. Cada usuario jugando un rol es una instancia de un actor. Maria, Juan y un software X son HelpDesk usando la funcionalidad del sistema de canalizar una solicitud. Cuando ellos usan el sistema, cada persona/cosa es una instancia del actor HelpDesk. Actores son Roles. En muchas situaciones, diferentes personas/cosas pueden jugar el rol de un actor en particular. Una secuencia de interacciones en un CU puede involucrar muchos actores. Pero un actor recibe el resultado de valor. Este actor se lo suele llamar actor principal y usualmente es el que inicia el CU. El resto son colaboradores 5

6 Los usuarios actúan! Comprando en una tienda Juan, el vendedor, asesora al cliente Mariana, la cajera, le cobra al cliente Fernando, el empaquetador, prepara el producto Diego, el repartidor, lleva hasta el domicilio Comprando en el drugstore de la esquina Don Lucho, el kiosquero, asesora al cliente Don Lucho, el kiosquero, le cobra al cliente Don Lucho, el kiosquero, prepara el producto vendedor cajero empaquetador Asociación de comunicación HelpDesk Se representa con una línea Canalizar solicitud Es un canal de comunicación entre el actor y el CU Es un camino de ida y vuelta propicia un diálogo El sistema alerta la llegada de una solicitud ElHelpDesk analiza la solicitud El HelpDesK consulta quién es el consultor apropiado El sistema sugiere el ranking de consultores posibles El HelpDesk selecciona el consultor El Sistema deriva la solicitud El Sistema notifica sobre el éxito de la derivación 6

7 Casos de uso y escenarios Canalizar solicitud HelpDesk Se pueden producir distintas alternativas al curso normal escenario1 escenario2 El sistema alerta solicitud El HelpDesk analiza la solicitud El HelpDesK consulta El sistema sugiere el ranking El HelpDesk selecciona consultor El Sistema deriva la solicitud El Sistema notifica OK derivación El sistema alerta solicitud El HelpDesk analiza la solicitud El HelpDesK consulta El sistema sugiere el ranking El HelpDesk selecciona consultor El Sistema deriva la solicitud El Sistema notifica Error derivación El HelpDesk selecciona alternativa El HelpDesk informa motivo El Sistema dispara alarma Diagrama de casos de uso Diagrama de CU muestra: Lo que hace el sistema (casos de uso) El límites del sistema (actores) La relación entre actores y casos de uso 7

8 Qué contiene un modelo de CU? Diagrama El sistema Actor 1 Actor 3 Caso de uso 1 Caso de uso 2 Caso de uso 3 Actor 2 Modelo CU. doc Descripción del modelo Lista de todos los actores Lista de todos los CU Texto Especif CU1. doc Breve descripción Flujo de eventos Especif CU1. doc Breve descripción Flujo de eventos Especif CU1. doc Breve descripción Flujo de eventos Qué contiene un modelo de CU? El diagrama nos da una vista gráfica del sistema. El texto nos da la descripción de los actores y casos de uso. La parte mas importante es el texto. Mucha gente tiene la idea equivocada que el modelado visual es dibujar unos cuantos monigotes, burbujitas y líneas. Los casos de uso implican escribir texto. Dibujar el modelo es solo una parte del esfuerzo. Por lo general mas del 75% del esfuerzo durante la captura de requerimientos se centra en escribir la descripcion textual de lo que sucede en cada caso de uso. La descripción de lo que sucede es llamado, flujo de eventos. 8

9 Flujo de eventos de un CU Hay un curso normal. Pueden haber varios caminos alternativos Estrategia de relevamiento Funcionalidad deseada Errores Excepciones Camino base La descripción de los CU debería hacerse respetando el siguiente orden: El curso normal muestra el comportamiento del sistema en un escenario ideal (happy case) Luego, la funcionalidad del sistema se puede expandir al contemplar posibles alternativas. Finalmente, tambien pueden suceder errores Funcionalidad no deseada 9

10 Algunas pautas para Casos de uso Describir solo los eventos visibles al actor Qué hace el actor Qué hace el sistema en respuesta Construir CU que provean valor a un actor Detallar solo hasta que todos tengan un entendimiento común del requerimiento. Bosquejar las interfaces de usuario no detallarlas. Usar los términos y vocabularios acordados Usar un lenguaje preciso y claro qué nombre se les coloca a los CU? Indicar el objetivo o valor que espera el actor. Usar verbo infinitivo para iniciar el nombre Imaginar una lista de cosas por hacer el <<Actor>> desea inscribirse para un curso inscripción para cursos acceso a inscripción usar sistema de inscripción llenado de inscripción completar inscripción? Por cuál optaría como nombre del CU? Por qué? 10

11 Pasos para documentar El sistema Actor 1 CU 1 CU2 Actor 2 Actor 3 CU3 planilla CU1. doc Breve descripción Flujo de eventos Especif CU1. doc Breve descripción Flujo de eventos Obs diseño Pre/pos condiciones Pasos para crear un Modelo de CU 1. Identificar Actores 2. Encontrar CU para esos actores 3. Documentar cada CU Descripción breve Flujo de eventos básico Identificar alternativas flujo de eventos 4. Detallar cada CU Agregar: pre y poscondiciones, observ. de diseño, relaciones, diagramas, otros 5. Estructurar el flujo de eventos de cada CU 11

12 Encontrar Actores Quién está operando con el sistema? cliente soporte Sistema Mesa de Ayuda el Cliente nunca toca el sistema, lo hace el HelDesk. y si el sistema es una aplicación web? cliente Para identificar actores del sistema Quién es el que está operando? El actor es algo que interactua con el sistema Sistema Mesa de Ayuda - on line - encontrar Actores Quién o qué usa el sistema? quién o qué toma información del sistema? Quién o qué provee informaión al sistema? En qué parte de la empresa se usa el sistema? Quién o qué mantiene o soporta el sistema? Con qué otros sistemas interactua el sistema? El actor es un rol, no una persona/cosa paricultar El nombre debería representar claramente ese Rol 12

13 Los actores son externos al sistema! Los actores permiten definir los límites del sistema Cómo se describen los Actores? Documento texto Nombre Breve descripción Qué o a quién representa el actor? Por qué el actor tiene una necesidad? Qué le interesa hacer con el sistema? Ejemplo HelpDesk Una persona que administra los requerimientos ingresados por mesa de ayuda HelpDesk Canalizar solicitud 13

14 Pasos para crear un Modelo de CU 1. Identificar Actores 2. Encontrar CU para esos actores 3. Documentar cada CU Descripción breve Flujo de eventos básico (curso normal) Identificar alternativas flujo de eventos 4. Detallar cada CU Agregar: pre y poscondiciones, observ. de diseño, relaciones, diagramas, otros 5. Estructurar el flujo de eventos de cada CU Encontrando Casos de uso qué objetivo intento lograr usando el sistema? Objetivo 1 Actor Objetivo 2 El Actor quiere usar el sistema para obtener algun valor 14

15 Encontrando Casos de uso Cuáles son los objetivos de cada actor? por qué el actor quiere usar el sistema? el actor debería crear, almacenar, registrar, modificar, eliminar o leer datos en el sistema?... Si!, por qué? el actor necesitaría informar al sistema de eventos externos o cambios? el actor necesita ser informado de ciertas ocurrencias o sucesos del en el sistema? cuáles son las tareas que el actor realiza para cumplir con su trabajo? El modelo está abarcando el sistema con todo el comportamiento correspondiente? Encontrando Casos de uso El mejor camino para encontrar CU es considerar que el actor necesita algo del sistema. Cada actor necesita cosas particulares esperando por algún valor observable por él. Si le preguntamos a todos los actores que quieren hacer con el sistema, tendremos el comportamiento completo del sistema. 15

16 Pasos para crear un Modelo de CU 1. Identificar Actores 2. Encontrar CU para esos actores 3. Documentar cada CU Descripción breve Flujo de eventos básico (curso normal) Identificar alternativas flujo de eventos 4. Detallar cada CU Agregar: pre y poscondiciones, observ. de diseño, relaciones, diagramas, otros 5. Estructurar el flujo de eventos de cada CU Cómo se describen los Casos de Uso? Documento texto Nombre Breve descripción Breve descripción del Rol y propósito del CU Ejemplo canalizar solicitud El HelpDesk deriva la solicitud del cliente al consultor sugerido por el sistema. HelpDesk Canalizar solicitud 16

17 Pasos para crear un Modelo de CU 1. Identificar Actores 2. Encontrar CU para esos actores 3. Documentar cada CU Descripción breve Flujo de eventos básico (curso normal) Identificar alternativas flujo de eventos 4. Detallar cada CU Agregar: pre y poscondiciones, observ. de diseño, relaciones, diagramas, otros 5. Estructurar el flujo de eventos de cada CU Documentar cada CU Nombre CU Se puede usar una plantilla que permita una estructura con un mejor orden. Los pasos del curso normal se pueden enumerar indicando en cada uno, el actor y la acción que realiza Descripción breve Flujo básico 1. paso uno 2. paso dos 3. paso tres A1 Alternativa paso1 A2 Alternativa paso2 A3 Alternativa paso3 17

18 cómo escribir cada paso del curso normal? Se podría utilizar la técnica de scripting Elementos de un script Rol: quien tiene la responsabilidad de llevar a cabo el comportamiento del sistema (actor) Responsabilidad: cada comportamiento desarrollado por un rol Dos tipos de actores: iniciador y participante Dos tipos de responsabilidades: acción y de servicio Una colaboración: entre ambos roles Iniciador Acción Participante Servicio Construcción de scripts 2.4 Contar el curso normal Obtener un libro: el estudiante solicita un libro, el bibliotecario verifica el estado del alumno para obtener un libro, consulta la disponibilidad del libro, registra la información del préstamo y entrega el libro al alumno. estructurarlo El estudiante Solicita un libro El bibliotecario I A P SAtiende al alumno El bibliotecario Consulta el estado del alumno para obtener un libro El sistema I A P SBrinda la información El bibliotecario Consulta la disponibilidad del libro El sistema I A P SBrinda la información acerca del libro El bibliotecario Registra la información del préstamo El sistema I A P SAlmacena la información El bibliotecario Entrega el libro El estudiante I A P SRecibe el libro 18

19 Pasos para crear un Modelo de CU 1. Identificar Actores 2. Encontrar CU para esos actores 3. Documentar cada CU Descripción breve Flujo de eventos básico (curso normal) Identificar alternativas flujo de eventos 4. Detallar cada CU Agregar: pre y poscondiciones, observ. de diseño, relaciones, diagramas, otros 5. Estructurar el flujo de eventos de cada CU Flujo de eventos (base y alternativo) Un flujo Base Escenario happy day escenario exitoso desde el comienzo al fin Muchos flujos alternativos Variantes normales (subflujos) Casos raros (excepciones) errores 19

20 Documentar el Flujo de Eventos Base qué evento inicia el CU? cómo termina el CU? el actor recibió el resultado de valor? Alternativo hay situaciones opcionales en el CU? qué casos raros pueden suceder? Qué variantes pueden suceder? qué puede suceder mal? qué puede no suceder? qué tipos de recursos pueden bloquearlo? Relaciones entre los Casos de Uso Hay distintos tipos de relaciones entre los CU «extender» (extend) se emplea para establecer una situación excepcional o de error, que no corresponde al camino normal del caso de uso básico «incluir» (include) se utiliza para extraer las parte comunes de los casos de uso; son casos de uso abstractos generalización 20

21 Relaciones entre los Casos de Uso En este diagrama se muestran todas las relaciones que se pueden dar entre CU (extensión, inclusión y generalización) Y también entre actores (generalización) Generalizacion entre actores Ejemplo: 21

22 cómo funciona la extensión entre CU? Ejemplo: cómo funciona la inclusión entre CU? 22

23 cómo funcional la generalización entre CU? Por qué documentar CU? Tamaño del CU borrador Caso de uso Me ayudan a encontrar todos los flujos alternativos Muy chico? Muy grande? Es más que un solo CU? Ayuda a descubrir aquello que no se conoce ayuda a determinar si el CU es demasiado chico o demasiado grande al escribir los pasos se pueden detectar pasos de otros CU o determinar si el CU tiene cosas para hacer o no agrega valor para encontrar todos los posibles flujos alternativos 23

24 Checkpoints Casos de Uso El modelo de CU presenta claramente el comportamiento del sistema Al leer el modelo de CU, es fácil entender lo que el sistema hace. Han sido identificados todos los CU; todos los CU juntos cumplen con el comportamiento requerido Todos los requerim. fucnionales están atados al menos a un CU El modelo de CU no contiene comportamiento superfluo; a todos los CU se les identifica perfectamente su trazabilidad Los nombre de los CU son únicos, intuitivos. El cliente/ usuario entienden los nombre y descripciones de los CU La descripción breve es representativa del comportamiento que está modelando el CU Cada CU está al menos asociado a un Actor (comentar excepción) Organizando el Modelo de CU Los CU se pueden organizar utilizando paquetes 24

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

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

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

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

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

Ejemplo: agencia de viajes por internet

Ejemplo: agencia de viajes por internet Introducción Modelado de casos de uso Propósito y definición Casos de uso y extracción de requisitos Carácter hipotético de los casos de uso El modelo de casos de uso Notación. Actores y casos de uso.

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Casos de uso UML. Miguel Vega mvega@ugr.es. Granada, octubre de 2010 LSI - UGR

Casos de uso UML. Miguel Vega mvega@ugr.es. Granada, octubre de 2010 LSI - UGR Especificación de UML Miguel Vega mvega@ugr.es LSI - UGR Granada, octubre de 2010 Especificación de Contenido 1 Introducción 2 3 Especificación de Contenido Plantilla de especificación Un ejemplo 4 5 Especificación

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

Aseguramiento de la calidad del software

Aseguramiento de la calidad del software Aseguramiento de la calidad del software Standard for Software Reviews and Audits [IEEE 1028] IEEE 1028 Para qué sirve Provee definiciones y requerimientos uniformes para los procesos de revisión y auditoría.

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

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

El modelo de casos de uso. Ingeniería de la Programación El modelo de casos de uso Ingeniería de la Programación Prácticas cas 1 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

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

Algunas Herramientas de Apoyo al Análisis y Diseño de Software. Agustín J. González ELO329: Diseño y programación orientados a objetos

Algunas Herramientas de Apoyo al Análisis y Diseño de Software. Agustín J. González ELO329: Diseño y programación orientados a objetos Algunas Herramientas de Apoyo al Análisis y Diseño de Software Agustín J. González ELO329: Diseño y programación orientados a objetos Resumen Para desarrollar software hay varias herramientas de gran utilidad

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

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS

CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS CAPÍTULO IV - GUÍA PARA HACER ANÁLISIS Y DISEÑO ORIENTADO A OBJETOS 4.1 Diferencias entre análisis y diseño La división entre el análisis y diseño es poco clara, el trabajo de los dos se mezcla continuamente

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

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

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

Í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

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD

BPMN BPMN BPMN. BPD Objetos de flujo - Actividades. BPD (Business Process Diagram) Notación de modelado de procesos de negocio BPD BPMN Notación de modelado de procesos de negocio BPMN Fue desarrollado por la BPMI (Business Process Management Initiative) Objetivos: Proveer una notación entendible para cualquiera desde el analista

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

Aplicaciones Web a tu medida!

Aplicaciones Web a tu medida! Nota aclaratoria: El presente documento se realizó tomando como base el documento titulado Ingeniería de Requisitos en Aplicaciones para la Web Un estudio comparativo escrito por María José Escalona (Universidad

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información 1 1. Definición y objetivos análisis.(del gr. ἀνάλυσις). 1. m. Distinción y separación de las partesdeun todo hasta llegar a conocer sus principios o elementos. 2. m.

Más detalles

Diagrama de casos de uso

Diagrama de casos de uso Diagrama de casos de uso Se utiliza para capturar los requerimientos funcionales de un sistema, de tal forma que plasman las relaciones entre los usuarios y el sistema. Contenido Pasos de construcción

Más detalles

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN ANÁLISIS Y DISEÑO DE SISTEMAS DEPARTAMENTO DE CIENCIAS E INGENIERÍA DE LA COMPUTACIÓN Clase 6: Ingeniería de Requerimientos Metododología y Ejemplo Primer Cuatrimestre 2015 Mg. María Mercedes Vitturini

Más detalles

6.6 DISEÑO. [Proceso]

6.6 DISEÑO. [Proceso] 6.6 DISEÑO. [Proceso] Durante un Ciclo de Desarrollo iterativo es posible pasar a la Fase de Diseño una vez completada la documentación de la fase de Análisis. Durante esta etapa se desarrolla una solución

Más detalles

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Modulo 03 UML: Vista de Casos de Uso Artefacto: Actores Catedrático MSC. Jose Juan Aviña Grimaldo e-mail josejuan_avina@gmail.com

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

BPMN 2.0. Bizagi Suite. Copyright 2014 Bizagi

BPMN 2.0. Bizagi Suite. Copyright 2014 Bizagi BPMN 2.0 Bizagi Suite BPMN 2.0 1 Tabla de Contenido Scope... 2 BPMN 2.0... 2 Qué es BPMN?... 2 Por qué es importante modelar con BPMN?... 3 Conceptos clave... 3 Proceso De Solicitud De Crédito... 3 Proceso

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

INGENIERÍA DEL SOFTWARE I. Univ. Cantabria Fac. de Ciencias. Especificación de Requisitos. Práctica 2

INGENIERÍA DEL SOFTWARE I. Univ. Cantabria Fac. de Ciencias. Especificación de Requisitos. Práctica 2 INGENIERÍA DEL SOFTWARE I Práctica 2 Especificación de Requisitos Univ. Cantabria Fac. de Ciencias María Sierra y Patricia López Nociones de UML para Requisitos: Casos de Uso Caso de Uso Una descripción

Más detalles

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s Especificación de requerimientos Diseño de bases de datos Documento de especificación del sistema 1. Definición del problema 2. Descripción funcional 2. 3. Restricciones 4. Diagramas de flujo de datos

Más detalles

Segunda Parte. Las Herramientas de Análisis y Diseño

Segunda Parte. Las Herramientas de Análisis y Diseño Segunda Parte Las Herramientas de Análisis y Diseño Capitulo IV 50 Diagramas de flujo de datos Capítulo IV Diagramas de Flujo de Datos 51 Capitulo IV Diagramas de flujo de datos Tabla de contenido 1.-

Más detalles

Control de Calidad de Software. Ing. Jorge Montaño Párraga

Control de Calidad de Software. Ing. Jorge Montaño Párraga Control de Calidad de Software Ing. Jorge Montaño Párraga Agenda Contenido Porque es necesario controlar la calidad? Que es testear? 7 Principios de Control de Calidad Proceso Fundamental de SQA Porque

Más detalles

Ingeniería de Negocios y Desarrollo de Sistemas de Información

Ingeniería de Negocios y Desarrollo de Sistemas de Información Ingeniería de Negocios y Desarrollo de Sistemas de Información Procesos de Negocios Modelos de negocio Ingeniería de Negocios: Notaciones Procedimientos Patrones Proceso de desarrollo de sistemas Metodologías

Más detalles

Etapas del desarrollo

Etapas del desarrollo Capítulo 4 Etapas del desarrollo Este capítulo documenta la aplicación del modelo presentado anteriormente, para el caso de la detección y clasificación de eventos sísmicos sobre señales digitales. El

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

PUD: Proceso de Desarrollo Unificado

PUD: Proceso de Desarrollo Unificado PUD: Proceso de Desarrollo Unificado 1 1998 Genealogía del PUD Rational Unified Process 5.0 1997 Rational Objectory Process 4.1 UML 1996 Rational Objectory Process 4.0 1995 Método Ericsson Rational Approach

Más detalles

ICONIX. Notas del método con ampliaciones y mejoras

ICONIX. Notas del método con ampliaciones y mejoras ICONIX Notas del método con ampliaciones y mejoras Juan Manuel Fernández Peña y María de los Ángeles Sumano López Colaboración de Josué Andrade Mirós Octubre de 2004 Método ICONIX Referencia El método

Más detalles

Taller de Desarrollo de Software

Taller de Desarrollo de Software Universidad de Talca Facultad de Ingeniería Campus Curicó Taller de Desarrollo de Software Informe de Requerimientos Integrantes: Carlos Guzmán Edgardo Ortiz Nelson Valdés Profesor: Victor Santander Fecha:

Más detalles

10325 Automating Administration with Windows PowerShell 2.0

10325 Automating Administration with Windows PowerShell 2.0 10325 Automating Administration with Windows PowerShell 2.0 Introducción Este curso de cinco días, provee a estudiantes con el conocimiento y habilidades para utilizar Windows PowerShell administración

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

Bienvenidos a la presentación: Introducción a conceptos básicos de programación.

Bienvenidos a la presentación: Introducción a conceptos básicos de programación. Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Diagramas de Actividad 2 Cuatrimestre 1998 1. INTRODUCCIÓN 1 2. DIAGRAMA DE ACTIVIDAD 1 2.1. SEMÁNTICA 1 2.2. NOTACIÓN 1 2.3. EJEMPLO 2 3. ACCIÓN 3 3.1. SEMÁNTICA 3 3.2. NOTACIÓN

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

Guía Metodológica para el diseño de procesos de negocio

Guía Metodológica para el diseño de procesos de negocio Guía Metodológica para el diseño de procesos de negocio La guía desarrollada para apoyar TBA, se diseñó con base en las metodologías existentes para el desarrollo BPM, principalmente en aquellas que soportan

Más detalles

TPV Práctica de la Asignatura de Programación Orientada a Objetos Escenario para el Curso 2014/2015 Febrero de 2014 Versión 1.00

TPV Práctica de la Asignatura de Programación Orientada a Objetos Escenario para el Curso 2014/2015 Febrero de 2014 Versión 1.00 TPV Práctica de la Asignatura de Programación Orientada a Objetos Escenario para el Curso 2014/2015 Febrero de 2014 Versión 1.00 Departamento de Lenguajes y Sistemas Informáticos Escuela Técnica Superior

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

CAPÍTULO III MARCO METODOLÓGICO. esta depende la estrategia de investigación. Para ello existe diversos tipos de

CAPÍTULO III MARCO METODOLÓGICO. esta depende la estrategia de investigación. Para ello existe diversos tipos de 74 CAPÍTULO III MARCO METODOLÓGICO En el proceso de desarrollo de un trabajo de investigación, la base fundamental del mismo es el tipo de investigación que se escoja, pues de esta depende la estrategia

Más detalles

Actividad ASI 1: Definición del Sistema

Actividad ASI 1: Definición del Sistema Actividad ASI 1: Definición del Sistema Descripción del sistema, delimitando su alcance Establecimiento de interfaces con otros sistemas Identificación de usuarios representativos ASI 1.1 Determinación

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

10550 Programming in Visual Basic with Microsoft Visual Studio 2010

10550 Programming in Visual Basic with Microsoft Visual Studio 2010 10550 Programming in Visual Basic with Microsoft Visual Studio 2010 Introducción Este curso le enseña sintaxis de lenguaje Visual Basic, estructura de programa e implementación al utilizar Microsoft Visual

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

Lenguaje de Script para Aventuras Gráficas y Presentaciones Interactivas.

Lenguaje de Script para Aventuras Gráficas y Presentaciones Interactivas. Lenguaje de Script para Aventuras Gráficas y Presentaciones Interactivas. (Documentación Preliminar) 5º Concurso Universitario de Software Libre Miguel Angel Pescador Santirso 1/13 LSAGPI- Documentación

Más detalles

CAPÍTULO 3 VISUAL BASIC

CAPÍTULO 3 VISUAL BASIC CAPÍTULO 3 VISUAL BASIC 3.1 Visual Basic Microsoft Visual Basic es la actual y mejor representación del viejo lenguaje BASIC, le proporciona un sistema completo para el desarrollo de aplicaciones para

Más detalles

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

ITLP-SIG-PG-001-IT-01 Toda copia en PAPEL es un Documento No Controlado a excepción del original Rev. 0

ITLP-SIG-PG-001-IT-01 Toda copia en PAPEL es un Documento No Controlado a excepción del original Rev. 0 Página 1 de 9 Todas las secciones del procedimiento deben llenarse, en caso de la omisión de alguna de ellas se indicará la frase no aplica. Nombre del documento: (a) Código : (b ) Revisión : (c ) Referencia

Más detalles

B.1 Checklist: evaluación heurística del producto software

B.1 Checklist: evaluación heurística del producto software Apéndice B Plantillas En las siguientes secciones se describen las plantillas textuales necesarias para la descripción de los documentos empleados en OPSOA. B.1 Checklist: evaluación heurística del producto

Más detalles

De los casos de uso a los casos de prueba. Caso práctico. Aplicación web Javier Gutiérrez / javierj@us.es

De los casos de uso a los casos de prueba. Caso práctico. Aplicación web Javier Gutiérrez / javierj@us.es De los casos de uso a los casos de prueba Caso práctico. Aplicación web Javier Gutiérrez / javierj@us.es Objetivo Objetivo: Mostrar cómo aplicar el proceso ETUC para la generación de casos de prueba a

Más detalles

Instructivo de Trabajo para Elaborar Procedimientos.

Instructivo de Trabajo para Elaborar Procedimientos. Referencia a la Norma ISO 9001-2008: 4.2.3 Página 1 de 10 Instructivo de Trabajo para Elaborar Procedimientos. Todas las secciones del procedimiento deben llenarse, en caso de la omisión de alguna de ellas

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

Weitzenfeld: Capítulo 6 1

Weitzenfeld: Capítulo 6 1 Weitzenfeld: Capítulo 6 Las descripciones de los casos de uso representan todas las posibles interacciones de los actores con el sistema para los eventos enviados o recibidos por los actores. En esta etapa

Más detalles

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas

Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Guía Rápida Proceso de Desarrollo OPENUP/OAS Universidad Distrital Francisco José de Caldas Oficina Asesora de Sistemas Información General del Documento Versión Actual del Documento 0.0.0.7 Descripción

Más detalles

Demo. TDD desde Cero. Acceptance Test Driven Development. www.iwt2.org formacion@iwt2.org

Demo. TDD desde Cero. Acceptance Test Driven Development. www.iwt2.org formacion@iwt2.org Demo TDD desde Cero Acceptance Test Driven Development www.iwt2.org formacion@iwt2.org Objetivos Objetivos Conocer cómo desarrollar un sistema software combinando pruebas de aceptación y TDD. Aprender

Más detalles

NCQTL MATERIALES NECESARIOS: ANTES DE COMENZAR: DIAPOSITIVA 1: USANDO EL MÉTODO CIENTÍFICO NOTA

NCQTL MATERIALES NECESARIOS: ANTES DE COMENZAR: DIAPOSITIVA 1: USANDO EL MÉTODO CIENTÍFICO NOTA ESPAÑOL/SPANISH APUNTES PARA EL PRESENTADOR USANDO EL MÉTODO CIENTÍFICO Esta guía presenta paso a paso el conjunto de materiales Interacciones interesantes y atrayentes: Usando el método científico. Este

Más detalles

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1.

PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA. Plan de Pruebas. File: 20130211-QA-INF-V2-PLAN DE PRUEBAS.odt STD-INF-GENERAL Versión: 1. Cliente: FCM-UNA Página 1 de 14 PLAN DE PRUEBAS SISTEMA DE GESTIÓN HOSPITALARIA Cliente: FCM-UNA Página 2 de 14 Tabla de contenido 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. ALCANCE 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

Identificación de requerimientos

Identificación de requerimientos Licenciatura en Informática Administración de requerimientos Identificación de requerimientos Licenciatura en Informática Sirva este material como apoyo a los apuntes de la asignatura Administración de

Más detalles

RUP. Rational Unified Process

RUP. Rational Unified Process RUP Rational Unified Process Rational Unified Process Basado en 6 mejores prácticas de la industria de software: Desarrollo incremental Administración de requisitos Uso de arquitecturas basadas en componentes

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Análisis y diseño orientado a objetos Contenido. Análisis y diseño orientado a objetos Muestra. Análisis y diseño orientado a objetos Muestra

Análisis y diseño orientado a objetos Contenido. Análisis y diseño orientado a objetos Muestra. Análisis y diseño orientado a objetos Muestra Análisis y diseño orientado a objetos Contenido Qué es análisis? Qué es diseño? Análisis y diseño OO Uso de UML Introducción al proceso de desarrollo Análisis y diseño orientado a objetos Muestra El proverbio

Más detalles

El Proceso Unificado

El Proceso Unificado El Proceso Unificado de Desarrollo de Software Prof. Gustavo J. Sabio Alcance de la presentación QA Entradas Proceso de desarrollo Salida equipo Cliente sistemas Cliente necesidades actividades varias

Más detalles

Analista Programador Javascript

Analista Programador Javascript Titulación certificada por EUROINNOVA BUSINESS SCHOOL Analista Programador Javascript Analista Programador Javascript Duración: 300 horas Precio: 260 * Modalidad: Online * Materiales didácticos, titulación

Más detalles

MEMORIA DE LAS ACTIVIDADES DESARROLLADAS PROYECTOS DE INNOVACIÓN EDUCATIVA CURSO 2014/2015

MEMORIA DE LAS ACTIVIDADES DESARROLLADAS PROYECTOS DE INNOVACIÓN EDUCATIVA CURSO 2014/2015 MEMORIA DE LAS ACTIVIDADES DESARROLLADAS PROYECTOS DE INNOVACIÓN EDUCATIVA CURSO 2014/2015 DATOS IDENTIFICATIVOS: 1. Título del Proyecto Herramienta para el Desarrollo de Aplicaciones Software con Metodologías

Más detalles

GESTIÓN DE SOFTWARE INFORME SOBRE. Evaluación de Productos UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA. Grupo 2

GESTIÓN DE SOFTWARE INFORME SOBRE. Evaluación de Productos UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA. Grupo 2 UNIVERSIDAD DE LA REPUBLICA - FACULTAD DE INGENIERÍA GESTIÓN DE SOFTWARE INFORME SOBRE Evaluación de Productos Grupo 2 Marcelo Caponi 3.825.139-0 Daniel De Vera 4.120.602-3 José Luis Ibarra 4.347.596-3

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones

INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones INGENIERÍA DEL SOFTWARE I Práctica 4 Interacciones Univ. Cantabria Fac. de Ciencias Patricia López Modelo de Casos de Uso vs Modelo de Análisis Modelo de Casos de Uso Modelo de Análisis Descrito con el

Más detalles

Una Introducción al UML. El Modelo de Componentes

Una Introducción al UML. El Modelo de Componentes Una Introducción al UML Autor: Geoffrey Sparks, Sparx Systems, Australia Traducción: Fernando Pinciroli (Solus S.A., Argentina) y Aleksandar Orlic (Craftware Consultores Ltda., Chile) www.sparxsystems.com.ar

Más detalles

Caso empresa ELÉCTRICA S.A.

Caso empresa ELÉCTRICA S.A. 1 Caso empresa ELÉCTRICA S.A. Eléctrica es una empresa dedicada a la venta de artículos Esta empresa cuenta con diferentes puntos de venta. Cada punto de venta cuenta con cajeros, vendedores y su propio

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos

CAPITULO 3 DISEÑO. El diseño del software es el proceso que permite traducir los requisitos 65 CAPITULO 3 DISEÑO 3.1. DISEÑO El diseño del software es el proceso que permite traducir los requisitos analizados de un sistema en una representación del software. 66 Diseño procedural Diseño de la

Más detalles

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

Deportes LSI 03. Sistema para Gestión de Artículos Deportivos LSI 03 Plan de Desarrollo Software. Versión 3.0 Deportes LSI 03 Sistema para Gestión de Artículos Deportivos LSI 03 Versión 3.0 Fecha: 02/01/2003 Historial de Revisiones Fecha Versión Descripción Autor 22/07/2002 0.9 Versión preliminar como propuesta

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

6 Anexos: 6.1 Definición de Rup:

6 Anexos: 6.1 Definición de Rup: 6 Anexos: 6.1 Definición de Rup: Es un producto del proceso de ingeniería de software que proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de una organización del desarrollo.

Más detalles

Ingeniería de Requisitos

Ingeniería de Requisitos Ingeniería de Requisitos Trazabilidad Departamento de Ciencias de la Computación Universidad de Chile Andrés Vignaga Contenido Trazabilidad Aplicaciones de Trazabilidad Trazabilidad Implícita y Explícita

Más detalles

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0

Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Proyecto Tutelkán Tutelkan Reference Process (TRP) Versión 2.0 Parte 3: TRP Avanzado MAYO 2009 Tabla de Contenidos PREFACIO...5 DESARROLLO Y MANTENCIÓN DE SOFTWARE...6 DESARROLLO DE REQUERIMIENTOS...7

Más detalles

Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo

Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo Derivación de requisitos y construcción de trazabilidad entre artefactos del proceso de desarrollo Cecilia Datko 1, Yanela Carllinni 2 Analista de Sistemas en el Depto. Sistemas de la Dirección de Informática

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

Plataforma Tecnológica Qué es Marino Imagine? La integración de los requerimientos de sistemas informáticos en la determinados sectores. infraestructura de la empresa ha sucedido de forma Sus carencias

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

Testing. Tipos, Planificación y Ejecución de Pruebas

Testing. Tipos, Planificación y Ejecución de Pruebas Testing Tipos, Planificación y Ejecución de Pruebas Contenido Definiciones del Testing de Software Objetivos, conceptos Tipos de Test Testing a-la RUP Rol del Testing en el proceso Artefactos Trabajadores

Más detalles

Sexto Congreso Argentino de Administración Pública Ciudad de Resistencia, Provincia del Chaco - 6 a 8 de Julio de 2011

Sexto Congreso Argentino de Administración Pública Ciudad de Resistencia, Provincia del Chaco - 6 a 8 de Julio de 2011 Sexto Congreso Argentino de Administración Pública Ciudad de Resistencia, Provincia del Chaco - 6 a 8 de Julio de 2011 Ponencia Implementación de una Wiki para la Gestión del Conocimiento Institucional

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Q-flow 3.1: Introducción a Q-flow

Q-flow 3.1: Introducción a Q-flow Q-flow 3.1: Introducción a Q-flow Código del manual: Qf310001ESP Versión: 1.1 Se aplica a: Q-flow 3.1 Última revisión: 13/12/2010 i Q f 3 1 0 0 0 1 E S P v 1. 1 Q - f l o w 3.1 Introducción a Q-flow Urudata

Más detalles

REGLAMENTO OFICIAL PROCESO DE PRÁCTICAS

REGLAMENTO OFICIAL PROCESO DE PRÁCTICAS Universidad Técnica Federico Santa Maria Departamento de Arquitectura G.S.F. 2013 REGLAMENTO OFICIAL PROCESO DE PRÁCTICAS A: Introducción Como parte fundamental del ciclo de formación profesional, todos

Más detalles

Patrones de software y refactorización de código

Patrones de software y refactorización de código Patrones de software y refactorización de código Introducción y antecedentes de los patrones de software Los patrones permiten construir sobre la experiencia colectiva de ingenieros de software habilidosos.

Más detalles

COMPARAR Y DESCRIBIR FIGURAS

COMPARAR Y DESCRIBIR FIGURAS COMPARAR Y DESCRIBIR FIGURAS 1er. Grado Universidad de La Punta Consideraciones Generales El abordaje de los contenidos geométricos en primer grado permitirá ofrecer a los niños oportunidades para el estudio

Más detalles