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

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

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

Transcripción

1 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial. El autor plantea el problema del diseño y construcción de software haciendo una comparación con la industria de la construcción, contemplando las siguientes fases: Herramientas Procesos Métodos Arquitectura Figura # 1 Herramientas. Soportan todos los aspectos de la empresa, explícitamente las actividades de arquitectura, métodos y procesos. Procesos. Permite el escalamiento de los métodos, de tal forma que puedan ser aplicados a proyectos de forma interactiva y en partes. Métodos. Establece de manera explícita los procedimientos etapa por etapa que deben seguirse para aplicar la arquitectura al proyecto. Arquitectura. Una buena estructura del sistema es fácil de entender, de cambiar y realizar pruebas y mantenimiento. Las propiedades del sistema determina como la arquitectura debe ser tratada durante el tiempo de vida. Las propiedades de la arquitectura son extremadamente importantes y forman la base del método. Diseño creativo Las actividades creativas de un desarrollo, consisten en la transformación de un conjunto de requerimientos y nociones vagas, en un plan estructurado de construcción y un plan de acción para su implementación. El diseño creativo tomando como referencia una base arquitectónica es seguir paso a paso los métodos y procesos con la asistencia de herramientas, para convertir los requerimientos dentro de una arquitectura viable para la construcción de un proyecto incluyendo la creación de prototipos. El ciclo de vida del sistema Un aspecto importantes durante el desarrollo del sistema, es considerar explícitamente el proceso de cambio Desarrollo del sistema Todos los sistemas cambian durante su ciclo de vida. Hoy en día el desarrollo de los nuevos métodos es conocer que cambios son los principales en la parte global del ciclo de vida, así como el costo del sistema. Una industrial del proceso debe por lo tanto saber sobre los cambios del sistema. Un sistema normalmente desarrolla cambios incorporándose en nuevas versiones. 37

2 Versión 1 Versión 1 Versión 2 Primer desarrollo del ciclo Versión n Figura # 2 La primera versión de un sistema representa una pequeña parte de una composición durante el ciclo de vida del sistema. REQUERIMIENTO ANALISIS CONSTRUCCION PRUEBA SISTEMA Figura # 3 Las actividades de un ciclo de vida son las mismas tanto para desarrollar una nueva versión de un sistema, así como para un sistema totalmente nuevo. La diferencia radica en que las entradas para cada etapa cambian en cada ciclo de vida. Modelo de análisis Especifica el comportamiento funcional del sistema bajo prácticamente circunstancias ideales y sin hacer alusión a un ambiente particular de implementación. Construcción L a primera actividad en la construcción consiste en la implementación de los detalles que conciernen a la arquitectura y construcción del plan, que es ir de una mayor abstracción a concretizar mas el plan. Diseño Formaliza el modelo de análisis en términos del ambiente de implementación y especifica la identidad de los bloques de construcción Prueba del sistema Consiste en la verificación del trabajo de cada uno de los paquetes de servicio definidos en el modelo de análisis Esta fase tiene lugar en varios niveles, desde funciones específicas, hasta el sistema completo. Desarrollo incremental El desarrollo del sistema es usualmente un proceso el cual toma varios años para su terminación. La especificación es seguida por el análisis, la construcción y prueba del sistema completo. Este método puede trabajar si todos los requerimientos del sistema son conocidos del conjunto de salida. 38

3 En la mayoría de los casos, conviene mejor desarrollar el sistema etapa por etapa, empezando con unas cuantas funciones principales, como se va aclarando la comprensión del sistema en cuanto a su funcionalidad se van agregando nuevas funciones, de esta forma el sistema va creciendo. Sistema de desarrollo y metodología Cuando se desarrolla un sistema grande es importante conocer como cada uno de los pasos del método interactúan y como ellos compiten dentro del desarrollo del proceso. Se hace hincapié en la discusión entre el proceso de desarrollo y las ideas básicas que hay detrás del método lo que determina la selección de una arquitectura de un universo de arquitecturas. Finalmente se agregan pocos comentarios acerca de cómo las herramientas CASE deberían ser diseñadas para soportar el desarrollo, iniciando desde las propiedades fundamentales de la arquitectura, métodos y procesos Modelos El sistema de desarrollo es una tarea compleja. Algunos aspectos diferentes han sido tomados en consideración. Se trabaja con 5 modelos: o El modelo de requerimientos: El objetivo es la captura de requerimientos funcionales. o El modelo de análisis: El objetivo es dar al sistema una estructura de objetos robusta y flexible a los cambios. o Modelo de diseño: Tiene como objetivo adoptar y refinar la estructura de objetos en el ambiente actual de implementación. o El modelo de implementación: Tiene como objetivo implementar el sistema o El modelo de prueba: Su objetivo es verificar el sistema. Análisis Construcción Prueba Modelo de Requerimientos Modelo de Análisis Modelo de Diseño Modelo de Implementación Modelo de Prueba Figura # 4 La idea básica de estos modelos es capturar el concepto inicial de todos los requerimientos funcionales y usar sus perspectivas. Es por eso que la relación entre ellos es importante. Para hacer posible el mantenimiento del sistema es también necesario que los modelos sean tangibles. Procesos y modelos Durante el desarrollo de un sistema se crea un modelo del sistema. El diseño de este modelo trabaja sobre un proceso de descripción con el cual será desarrollado el sistema. Esos modelos son expresados en un cierto espacio de información. Cada proceso toma uno o varios modelos y transforma esto dentro de otros modelos. 39

4 Entrada Proceso Salida Modelo A Modelo B Figura # 5 Los procesos transforman un modelo en otro modelo El modelo final será una descripción del sistema, completo y probado. Esta descripción normalmente consiste del código fuente y su documentación. Proceso de análisis El proceso de análisis produce dos modelos, a partir de la especificación de requerimientos, un modelo de requerimientos es creado para especificar toda la funcionalidad del sistema. Esto es principalmente hecho por: casos de uso en el modelo de casos de uso, el cual forma parte del modelo de requerimientos. El modelo de requerimientos es la base de otro modelo creado por el proceso de análisis, llamado modelo de análisis. El modelo de análisis es la base de la estructura del sistema. En este modelo se especifican todos los objetos lógicos que serán incluidos en el sistema y como están relacionados y agrupados. Modelo de Requerimientos diseño implementación Modelo de Análisis Modelo de Diseño Modelo de Implementación Modelo de requerimientos Figura # 6 Actores y Casos de Uso La primera transformacion hecha de la especificacion de requerimientos para el modelo de requerimientos consiste en: o o o Un modelo de caso de uso Descripción de la interfase Un modelo en el dominio del problema 40

5 Actor Caso de uso Figura # 7 El modelo de caso de uso usa actores y caso de uso Estos conceptos son usados para definir qué existe contacto externo con el sistema (actores), y qué debería ser hecho por el sistema (caso de uso). Los actores representan quienes interactúan con el sistema. Representan todas las necesidades de cambio de información con el sistema. Dado que el actor representa la parte exterior del sistema no se describirán detalles de ellos. La diferencia entre un actor y un usuario radica en que el usuario es la persona que usa el sistema, mientras que el actor es un rol que el usuario puede jugar. EJEMPLO DE UN MODELO DE CASO DE USO. Jugador Jugar_Pacman Figura # 8 Manejo del diseño de un caso de uso El modelo del sistema usará un manejo de casos de uso. Cuando se desea un cambio en el comportamiento del sistema, se remodela el actor y el caso de uso apropiado. Otra característica importante del modelo de requerimientos es que podemos discutir esto con el usuario y encontrar sus requerimientos y preferencias. Este modelo es fácil de entender y formularlo desde la perspectiva del usuario y generar un buen sistema de acuerdo a sus requerimientos. El soporte del modelo de caso de usos es apropiado para desarrollar las interfaces de los casos de uso. Aquí un prototipo de interfase de usuario es una buena herramienta. El modelo de caso de uso controla la formulación de otros modelos. Esto es desarrollado en cooperación con el modelo de dominio de objeto. 41

6 Modelo de casos de uso Expresado en términos de realizado por probado en Estructurado por mplementado por Clases... SI SI SI Modelo en el Modelo de análisis Modelo de diseño Modelo de Modelo de prueba Dominio de objetos implementación Figura # 9 Modelo de análisis Se ha visto que el modelo de requerimientos tiene como objetivo definir las limitaciones del sistema y especificar su comportamiento. Cuando el modelo de requerimientos ha sido desarrollado y aprobado por los usuarios se puede iniciar el desarrollo del sistema. La información para este sistema se enfoca en la captura de: Información: Especifica la información de ayuda en el sistema. Así como describe el estado interno del sistema. Comportamiento: Especifica el comportamiento que adopta el sistema. Especifica cuando y como el sistema cambia de estado. Presentación: Detalla la presentación del sistema al mundo exterior. Comportamiento Presentación Información Dimensiones del modelo de análisis Figura # 10 42

7 Existen varios tipos de objetos usados para la estructura del sistema en el modelo de análisis Objeto entidad Objeto de interfase Objeto de control Figura # 11 Cada objeto al menos captura dos de las tres dimensiones del modelo de análisis, sin embargo cada uno de ellos tiene cierta inclinación hacia una de las dimensiones. comportamiento presentación información Figura # 12 El modelo de requerimientos es estructurado en el modelo de análisis El modelo de análisis esta formado a partir del modelo de casos de uso. Cada caso de uso será divido en objetos de 3 tipos. En el modelo de requerimientos se especifica toda la funcionalidad del sistema. Esta funcionalidad debe ser ahora conformada para obtener una estructura completa y robusta. Funcionalidad de un caso de uso Asignando responsabilidades a objetos. Objeto de interfase Objeto entidad Objeto de control Figura # 13. Funcionalidad de un caso de uso convertida a responsabilidades de Objetos. 43

8 La funcionalidad de un caso de uso convertida a responsabilidades de objetos. La partición se realiza básicamente de acuerdo a los siguientes principios: Aquella funcionalidad de casos de uso la cual es directamente dependiente del ambiente del sistema, es representada por objetos de interfase. Aquella funcionalidad derivada del almacenamiento y manejo de información, la cual de manera natural no encaja en ningún objeto de interfase, es representada por objetos entidad. Aquella funcionalidad especificada para unos pocos casos de uso y que de manera natural no encaja en ninguno de los objetos anteriores, es representada por objetos de control. El modelo de diseño de objetos El proceso de construcción edifica el sistema usando tanto el modelo de análisis y el modelo de requerimientos. Primero se crea el modelo de diseño que es un refinamiento y formalización del modelo de análisis. Al inicio del trabajo cuando se desarrolla el modelo de diseño es para adaptarlo a la implementación del ambiente actual. Comportamiento Ambiente de Implementación Información Presentación Figura # 14 Una diferencia entre el modelo de análisis y el modelo de diseño es que el modelo de análisis debe ser visto como un modelo conceptual o lógico del sistema, y el modelo de diseño contiene el código, por lo cual el modelo de diseño deberá ser una representación de la manera como el código fuente es estructurado, manejado y escrito. Modelo de análisis Modelo de diseño Empiezan a aparecer consecuencias del ambiente de implementación Refinamiento. Figura # 15 Transición del modelo de análisis al modelo de diseño 44

9 3.1.4 Bloques El concepto de bloque describe la intención de cómo el código debe ser producido. Los bloques son el diseño de objetos y ellos se dibujan como rectángulos. Un bloque normalmente apunta para implementar un objeto de la etapa de análisis, aquí puede ser posible usar los diferentes tipos de bloques:! Bloque de interfase.! Bloque de Entidad.! Bloque de Control. Figura # 16 Bloque Diagrama de interacción Para describir una secuencia de estímulos se usan los diagramas de interacción. Se puede describir como varios bloques se comunican mediante envió de estímulos de uno a otro. Como una base para esa interacción se usa otra vez el modelo de caso de uso. Describe en detalle para cada caso de uso, una secuencia de estimulo la cual es enviada entre los bloques. bloque 1 bloque 1 bloque 3 bloque 4 s1 s2 s3 s4 Figura # 17 Diagrama de Secuencia Genérico La Figura # 17 muestra la representación de un diagrama de secuencia, donde el tiempo avanza de arriba hacia abajo y la flechas indican comunicación entre objetos. En la Figura # 18 se muestra un ejemplo práctico usando el problema del Pacman. 45

10 : Jugador : Pacman : Fantasma Camina_ Camina_ Come_Fantasma(Valor) Come_Fantasma(Pacman) Figura # 18 Diagrama de Secuencia del ejemplo Trabajando con el modelo de diseño Durante la construcción del proyecto, se procede a la edificación del modelo de diseño. Para cada objeto en el modelo de análisis, se asigna un bloque en el modelo de diseño. Cuando se tiene que crear la estructura del bloque, se dibuja un diagrama de interacción para mostrar como los bloques se comunican. Normalmente se dibuja un diagrama de interacción para cada caso de uso. El comportamiento del objeto. Como un nivel intermedio, considerando la parte interna del objeto, antes de iniciar la implementación se puede usar una gráfica de transición de estado, su propósito es proporcionar una descripción simplificada, que mejore la comprensión del bloque, sin tener que bajar a nivel de código fuente, proporcionando una descripción que es menos dependiente del lenguaje de programación seleccionado. En este tipo de gráficas se describe cual estímulo puede ser recibido y que va a suceder cuando el estímulo es recibido. Esta gráfica usa los símbolos mostrados en la Figura #

11 Inicio Regreso de mensaje Estado Envía señal Envía mensaje Recibe señal Recibe mensaje Realiza un trabajo Figura # 19, Notación para las gráficas de transición de estados. El modelo de Implementación La implementación del modelo consiste de la notación del código. La información de espacio es la opción del lenguaje de programación que se usa. no necesariamente se requiere de un lenguaje de programación orientada a objeto, sin embargo, si se recomienda el uso de un lenguaje de programación orientada a objeto, desde la concepción inicial hasta la construcción. La base para la implementación es el modelo de diseño. Aquí se especifica la interfase de cada bloque. El modelo de prueba El modelo de prueba es el ultimo modelo a construir. Describe simplemente el estado de resultados de la prueba. El modelo de requerimientos de nuevo representa una herramienta potente de prueba, al probar cada caso de uso, se verifica que los objetos se comuniquen correctamente en dicho caso de uso. De manera simular se verifica la interfase de usuario, descrita en el modelo de requerimientos, con todo lo anterior, el modelo de requerimientos es la base de verificado para el modelo de prueba. 47

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes:

Proceso Unificado de Rational PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: PROCESO UNIFICADO DE RATIONAL (RUP) El proceso de desarrollo de software tiene cuatro roles importantes: 1. Proporcionar una guía de actividades para el trabajo en equipo. (Guía detallada para el desarrollo

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

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

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software Principio de Diseño Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002 Introducción al Diseño de Software Qué es el diseño? Representación ingenieril

Más detalles

Figure 7-1: Phase A: Architecture Vision

Figure 7-1: Phase A: Architecture Vision Fase A Figure 7-1: Phase A: Architecture Vision Objetivos: Los objetivos de la fase A son: Enfoque: Desarrollar una visión de alto nivel de las capacidades y el valor del negocio para ser entregado como

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

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

6.8 La Arquitectura del Sistema. [Proceso]

6.8 La Arquitectura del Sistema. [Proceso] 6.8 La Arquitectura del Sistema. [Proceso] En el Caso de Estudio se ha hecho énfasis en los objetos del Dominio del problema, ya que representan la esencia del sistema y definen su comportamiento. Sin

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

BPMN básico. Clase Modelos de Procesos. Javier Bermudez (jbermude@uc.cl)

BPMN básico. Clase Modelos de Procesos. Javier Bermudez (jbermude@uc.cl) BPMN básico Clase Modelos de Procesos Javier Bermudez (jbermude@uc.cl) Para qué modelar? Para sacar el mejor provecho a los artefactos creados por el hombre 2 BPMN Historia Mayo 2004: BPMI Lanza propuesta

Más detalles

7.1 Arquitectura de clases

7.1 Arquitectura de clases 7.1 Arquitectura de clases El modelo de analisis tiene como objetivo generar una arquitectura de objetos que sirva como base para el diserio del sistema. Como se discutio en el capitulo 3, dependiendo

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

Workflows? Sí, cuántos quiere?

Workflows? Sí, cuántos quiere? Workflows? Sí, cuántos quiere? 12.11.2006 Servicios Profesionales Danysoft Son notables los beneficios que una organización puede obtener gracias al soporte de procesos de negocios que requieran la intervención

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

Capítulo 4 Análisis y diseño del software de los Robots

Capítulo 4 Análisis y diseño del software de los Robots Capítulo 4 Análisis y diseño del software de los Robots En el capítulo del diseño mecánico de los robots se muestran los distintos sensores que se utilizarán como entradas, así como los motores que deberán

Más detalles

-OPS/CEPIS/01.61(AIRE) Original: español Página 11 5. Estructura del programa de evaluación con personal externo

-OPS/CEPIS/01.61(AIRE) Original: español Página 11 5. Estructura del programa de evaluación con personal externo Página 11 5. Estructura del programa de evaluación con personal externo 5.1 Introducción Esta sección presenta la estructura del programa de evaluación con personal externo. Describe las funciones y responsabilidades

Más detalles

CAPÍTULO 3 Servidor de Modelo de Usuario

CAPÍTULO 3 Servidor de Modelo de Usuario CAPÍTULO 3 Servidor de Modelo de Usuario Para el desarrollo del modelado del estudiante se utilizó el servidor de modelo de usuario desarrollado en la Universidad de las Américas Puebla por Rosa G. Paredes

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

App para realizar consultas al Sistema de Información Estadística de Castilla y León

App para realizar consultas al Sistema de Información Estadística de Castilla y León App para realizar consultas al Sistema de Información Estadística de Castilla y León Jesús M. Rodríguez Rodríguez rodrodje@jcyl.es Dirección General de Presupuestos y Estadística Consejería de Hacienda

Más detalles

Metodologías de diseño de hardware

Metodologías de diseño de hardware Capítulo 2 Metodologías de diseño de hardware Las metodologías de diseño de hardware denominadas Top-Down, basadas en la utilización de lenguajes de descripción de hardware, han posibilitado la reducción

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

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

Proceso de desarrollo del software modelo en cascada

Proceso de desarrollo del software modelo en cascada Proceso de desarrollo del software modelo en cascada Análisis: Necesidades del usuario especificaciones Diseño: Descomposición en elementos que puedan desarrollarse por separado especificaciones de cada

Más detalles

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos.

Actividades para mejoras. Actividades donde se evalúa constantemente todo el proceso del proyecto para evitar errores y eficientar los procesos. Apéndice C. Glosario A Actividades de coordinación entre grupos. Son dinámicas y canales de comunicación cuyo objetivo es facilitar el trabajo entre los distintos equipos del proyecto. Actividades integradas

Más detalles

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

Capítulo VI. Diagramas de Entidad Relación

Capítulo VI. Diagramas de Entidad Relación Diagramas de Entidad Relación Diagramas de entidad relación Tabla de contenido 1.- Concepto de entidad... 91 1.1.- Entidad del negocio... 91 1.2.- Atributos y datos... 91 2.- Asociación de entidades...

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

comunidades de práctica

comunidades de práctica 1. Introducción CoSpace es una plataforma web diseñada para proporcionar un espacio virtual de interacción y colaboración entre formadores en comunidades virtuales. Se originó como resultado de las necesidades

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto

Más detalles

CAPITULO V. HERRAMIENTA CASE (Rational Rose, C++)

CAPITULO V. HERRAMIENTA CASE (Rational Rose, C++) CAPITULO V HERRAMIENTA CASE (Rational Rose, C++) 5.1 HERRAMIENTA CASE La documentación del UML ha propiciado el desarrollo de herramientas CASE, las cuales cubren el ciclo de vida del software y además

Más detalles

BPMN Business Process Modeling Notation

BPMN Business Process Modeling Notation BPMN (BPMN) es una notación gráfica que describe la lógica de los pasos de un proceso de Negocio. Esta notación ha sido especialmente diseñada para coordinar la secuencia de los procesos y los mensajes

Más detalles

CRONO SISTEMA DE CONTROL DE PRESENCIA. Software abierto. Distintas opciones para realizar las picadas. Web personal para cada usuario

CRONO SISTEMA DE CONTROL DE PRESENCIA. Software abierto. Distintas opciones para realizar las picadas. Web personal para cada usuario Software abierto Distintas opciones para realizar las picadas Web personal para cada usuario Gestión de incidencias Informes individuales y colectivos CRONO SISTEMA DE CONTROL DE PRESENCIA Qué es Crono?

Más detalles

Metodologías para generación de Sistemas Orientados a Objetos

Metodologías para generación de Sistemas Orientados a Objetos Metodologías para generación de Sistemas Orientados a Objetos Análisis y Diseño (Tecnologías) Orientado a Objetos Dr. Leopoldo Altamirano Robles 22 septiembre, 2003 Alicia Morales Reyes Alma Rosa Rugerio

Más detalles

DISEÑO DE FUNCIONES (TRATAMIENTOS)

DISEÑO DE FUNCIONES (TRATAMIENTOS) DISEÑO DE FUNCIONES (TRATAMIENTOS) Diseño Estructurado. Estrategias para Derivar el Diagrama de Estructura. Diseño de Módulos Programables. 1. DISEÑO ESTRUCTURADO El Diseño es el proceso por el cual se

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

SISTEMAS DE INFORMACIÓN I TEORÍA

SISTEMAS DE INFORMACIÓN I TEORÍA CONTENIDO: CICLO DE VIDA DE DESARROLLO DE SI FASES GENÉRICAS DEL CICLO DE VIDA DE DESARROLLO DE SI VISIÓN TRADICIONAL DEL CICLO DE VIDA DE DESARROLLO DE SI DE DESARROLLO DE SI: ANÁLISIS Material diseñado

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 de Simulación aplicado a entornos de e-learning

Software de Simulación aplicado a entornos de e-learning Software de Simulación aplicado a entornos de e-learning 2009 Laboratorio de Investigación de Software Universidad Tecnológica Nacional Facultad Regional Córdoba Titulo del Proyecto Software de Simulación

Más detalles

K2BIM Plan de Investigación - Comparación de herramientas para la parametrización asistida de ERP Versión 1.2

K2BIM Plan de Investigación - Comparación de herramientas para la parametrización asistida de ERP Versión 1.2 K2BIM Plan de Investigación - Comparación de herramientas para la parametrización asistida de ERP Versión 1.2 Historia de revisiones Fecha VersiónDescripción Autor 08/10/2009 1.0 Creación del documento.

Más detalles

capitulo3 MARCO TEÓRICO Para el diseño de la reubicación de los procesos se hará uso de la Planeación

capitulo3 MARCO TEÓRICO Para el diseño de la reubicación de los procesos se hará uso de la Planeación capitulo3 MARCO TEÓRICO Para el diseño de la reubicación de los procesos se hará uso de la Planeación Sistemática de Layout, SLP por sus siglas en inglés. Se hará uso de la simulación para comparar el

Más detalles

2 EL DOCUMENTO DE ESPECIFICACIONES

2 EL DOCUMENTO DE ESPECIFICACIONES Ingeniería Informática Tecnología de la Programación TEMA 1 Documentación de programas. 1 LA DOCUMENTACIÓN DE PROGRAMAS En la ejecución de un proyecto informático o un programa software se deben de seguir

Más detalles

METODOLOGÍA PARA LA MEJORA Y DIGITALIZACIÓN DE TRÁMITES. Etapa 1: Diagnóstico Cómo es mi proceso actual?

METODOLOGÍA PARA LA MEJORA Y DIGITALIZACIÓN DE TRÁMITES. Etapa 1: Diagnóstico Cómo es mi proceso actual? METODOLOGÍA PARA LA MEJORA Y DIGITALIZACIÓN DE TRÁMITES Etapa 1: Diagnóstico Cómo es mi proceso actual? El primer paso para mejorar un trámite, ya sea con miras a digitalizarlo o solo para mejorarlo en

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

Anteproyecto Fin de Carrera

Anteproyecto Fin de Carrera Universidad de Castilla-La Mancha Escuela Superior de Informática Anteproyecto Fin de Carrera DIMITRI (Desarrollo e Implantación de Metodologías y Tecnologías de Testing) Dirige: Macario Polo Usaola Presenta:

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

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

Análisis y Diseño de Aplicaciones

Análisis y Diseño de Aplicaciones Análisis y Diseño de Aplicaciones Ciclo de Vida Docente: T/RT Gonzalo Martínez CETP EMT Informática 3er Año Introducción En el desarrollo de sistemas, el ciclo de vida son las etapas por las que pasa un

Más detalles

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática

Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática Universidad acional Experimental Del Táchira Decanato de Docencia Departamento de Ingeniería en Informática Metodología Evolutiva Incremental Mediante Prototipo y Técnicas Orientada a Objeto (MEI/P-OO)

Más detalles

En un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuando y Como hacerlo. 6

En un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuando y Como hacerlo. 6 2. MÉTODO, METODOLOGÍA Y MÉTRICA 2.1 MÉTODO Un método de ingeniería del software es un enfoque estructurado para el desarrollo de software cuyo propósito es facilitar la producción de software de alta

Más detalles

Filosofía del Ministerio de la Célula

Filosofía del Ministerio de la Célula CÉLULAS LECCIÓN 6 Filosofía del Ministerio de la Célula Propósito de la Lección El propósito de esta lección es examinar el papel de los grupos pequeños en una estrategia general para la plantación de

Más detalles

Primer avance de proyecto de software para la gestión de inscripciones en cursos

Primer avance de proyecto de software para la gestión de inscripciones en cursos Primer avance de proyecto de software para la gestión de inscripciones en cursos 1. Introducción Andrés Felipe Bustamante García, Carolina Sarmiento González En este documento se presentan los resultados

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

Más detalles

Orientación acerca del enfoque basado en procesos para los sistemas de gestión de la calidad

Orientación acerca del enfoque basado en procesos para los sistemas de gestión de la calidad Orientación acerca del enfoque basado en procesos para los sistemas de gestión de la calidad Documento: ISO/TC 176/SC 2/N 544R Mayo 2001 ISO Traducción aprobada el 2001-05-31 Prólogo de la versión en español

Más detalles

II. Relación con Terceros

II. Relación con Terceros II. Relación con Terceros Introducción a la Relación con Terceros Los terceros se refieren a las entidades con las cuales se realizan transacciones en la organización. Hay tres tipos de terceros, están:

Más detalles

80294 Microsoft Dynamics CRM 2011 Customization and Configuration

80294 Microsoft Dynamics CRM 2011 Customization and Configuration 80294 Microsoft Dynamics CRM 2011 Customization and Configuration Introducción Este curso describe las técnicas requeridas para personalizar Microsoft Dynamics CRM para cumplir las necesidades especializadas

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

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

Gestión y Desarrollo de Requisitos en Proyectos Software

Gestión y Desarrollo de Requisitos en Proyectos Software Gestión y Desarrollo de Requisitos en Proyectos Software Ponente: María Jesús Anciano Martín Objetivo Objetivo Definir un conjunto articulado y bien balanceado de métodos para el flujo de trabajo de Ingeniería

Más detalles

Figure 9-1: Phase C: Information Systems Architectures

Figure 9-1: Phase C: Information Systems Architectures FASE C Figure 9-1: Phase C: Information Systems Architectures Objetivos Los objetivos de la Fase C son: Desarrollar la arquitectura de sistemas de información objetivo (datos y aplicaciones), que describe

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO)

IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO) IAP 1009 - TÉCNICAS DE AUDITORÍA APOYADAS EN ORDENADOR (TAAO) Introducción 1. Como se indica en la Norma Internacional de Auditoría 401, "Auditoría en un contexto informatizado", los objetivos globales

Más detalles

Unidad 9. Implementación. M.C. Martín Olguín

Unidad 9. Implementación. M.C. Martín Olguín Unidad 9 Implementación M.C. Martín Olguín Implementación Es la traducción directa del diseño en un lenguaje de programación. Es decir, en la implementación se construyen los componentes: Archivos de código

Más detalles

Traducción del. Our ref:

Traducción del. Our ref: Traducción del Documento: Our ref: Secretaría del ISO/TC 176/SC 2 Fecha: 15 de octubre de 2008 A los Miembros del ISO/TC 176/SC 2 - Gestión de la Calidad y Aseguramiento de la Calidad/ Sistemas de la Calidad

Más detalles

Planificación, Gestión y Desarrollo de Proyectos

Planificación, Gestión y Desarrollo de Proyectos Planificación, Gestión y Desarrollo de Proyectos Conceptos básicos Planificación de un proyecto Gestión de un proyecto Desarrollo de un proyecto 1 Conceptos básicos: Proyecto Conjunto de actividades que

Más detalles

Ingeniería de Software. Pruebas

Ingeniería de Software. Pruebas Ingeniería de Software Pruebas Niveles de prueba Pruebas unitarias Niveles Pruebas de integración Pruebas de sistema Pruebas de aceptación Alpha Beta Niveles de pruebas Pruebas unitarias Se enfocan en

Más detalles

Escenarios. Diapositiva 1. Ingeniería de Requerimientos: Escenarios

Escenarios. Diapositiva 1. Ingeniería de Requerimientos: Escenarios Escenarios Diapositiva 1. Ingeniería de Requerimientos: Escenarios Diapositiva 2. Uso de lenguaje natural Debido a que uno de los objetivos de la Ingeniería de Requisitos es aumentar el conocimiento del

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

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

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre

Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Modelo para el Aseguramiento de Calidad en el Desarrollo de Software Libre Cenditel, Mayo 2011 Licencia de Uso Copyright (c) 2010, Alvarez J., Solé S., Briceño R., Fundación CENDITEL. La Fundación CENDITEL

Más detalles

Sistema de Mensajería Empresarial para generación Masiva de DTE

Sistema de Mensajería Empresarial para generación Masiva de DTE Sistema de Mensajería Empresarial para generación Masiva de DTE TIPO DE DOCUMENTO: OFERTA TÉCNICA Y COMERCIAL VERSIÓN 1.0, 7 de Mayo de 2008 CONTENIDO 1 INTRODUCCIÓN 4 2 DESCRIPCIÓN DE ARQUITECTURA DE

Más detalles

Ciclo de vida del software

Ciclo de vida del software Ciclo de vida del software Definición El proceso que se sigue para construir, entregar y hacer evolucionar el software, desde la concepción de una idea hasta la entrega y el retiro del sistema. Confiable,

Más detalles

La toma de decisiones está presente dentro de la vida de la mayoría de las personas. Los

La toma de decisiones está presente dentro de la vida de la mayoría de las personas. Los ANEXO II. Sistema de Soporte a las Decisiones-SSD La toma de decisiones está presente dentro de la vida de la mayoría de las personas. Los gerentes día a día deben tomar decisiones también, la diferencia

Más detalles

EL PROCESO DE BENCHMARKING

EL PROCESO DE BENCHMARKING EL PROCESO DE BENCHMARKING Michael J. Spendolini El benchmarking es un proceso sistemático y continuo para evaluar los productos, servicios y procesos de trabajo de las organizaciones que son reconocidas

Más detalles

Ingeniería del Software I

Ingeniería del Software I - 1 - Ingeniería del Software I Introducción al Modelo Conceptual 2do. Cuatrimestre 2005 INTRODUCCIÓN... 2 CLASES CONCEPTUALES... 3 ESTRATEGIAS PARA IDENTIFICAR CLASES CONCEPTUALES... 3 Utilizar lista

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

COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE

COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE COPPEL MANUAL TÉCNICO MCC DE SISTEMAS PROGRAMACIÓN DESCRIPCIÓN DEL PROCESO DE ARQUITECTURA DE SOFTWARE Creado en May/14 Objetivo: Contar con una guía de las actividades que se deben realizar en esta fase,

Más detalles

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos:

Tutorial de UML. Introducción: Objetivos: Audiencia: Contenidos: Tutorial de UML Introducción: El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende

Más detalles

Implementando un ERP La Gestión del Cambio

Implementando un ERP La Gestión del Cambio Artículos> Implementando un ERP - La Gestión del Cambio Artículo Implementando un ERP La Gestión del Cambio 1 Contenido Sumario Ejecutivo 3 Los sistemas ERP flexibilizan la gestión de la empresa y su cadena

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

6.4 ESTRATEGIAS DE PRUEBA

6.4 ESTRATEGIAS DE PRUEBA Prueba del sistema Prueba de validación Prueba de integración Prueba de Unidad Código Diseño Requisitos Ingeniería del Sistema Las pruebas del software aplican similar estrategia moviéndonos de adentro

Más detalles

PROCESO ADMINISTRACIÓN DE RECURSOS TECNOLÓGICOS SUBPROCESO ADMINISTRACIÓN DE CONTINGENCIAS

PROCESO ADMINISTRACIÓN DE RECURSOS TECNOLÓGICOS SUBPROCESO ADMINISTRACIÓN DE CONTINGENCIAS Objetivo Este subproceso establece las actividades que se realizan para la planeación y control de respaldos y desastres relacionados con los recursos informáticos existentes en el Senado de La República

Más detalles

Unidad 1. Fundamentos en Gestión de Riesgos

Unidad 1. Fundamentos en Gestión de Riesgos 1.1 Gestión de Proyectos Unidad 1. Fundamentos en Gestión de Riesgos La gestión de proyectos es una disciplina con la cual se integran los procesos propios de la gerencia o administración de proyectos.

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

Metodología centrada en la Experiencia del Usuario

Metodología centrada en la Experiencia del Usuario Metodología centrada en la Experiencia del Usuario Esta metodología fue creada por Jesse James Garrett, se describe a detalle en su libro The Elements of User Experience, consiste en asegurarse que ningún

Más detalles

ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Resumen

ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Resumen ITZOFT, una metodología de desarrollo de sistemas basada en el Proceso Unificado de Rational. Sergio Valero Orea, svalero@utim.edu.mx, UTIM, Izúcar de Matamoros, Puebla. Resumen El desarrollo de sistemas

Más detalles

SISTEMA DE ESPECIICACION DE REQUERIMIENTOS

SISTEMA DE ESPECIICACION DE REQUERIMIENTOS SISTEMA DE ESPECIICACION DE REQUERIMIENTOS Presentado por: Jefferson Peña Cristian Álvarez Cristian Alzate 10 CONTENIDO 1. INTRODUCCIÓN 1.1. PROPÓSITO 1.2. AMBITO DEL SISTEMA 1.3. DEFINICIONES, ACRÓNIMOS

Más detalles

Usos de los Mapas Conceptuales en Educación

Usos de los Mapas Conceptuales en Educación Usos de los Mapas Conceptuales en Educación Carmen M. Collado & Alberto J. Cañas Introducción Los mapas conceptuales son una poderosa herramienta de enseñanza-aprendizaje. Su utilización en (y fuera de)

Más detalles

Preguntas más frecuentes sobre PROPS

Preguntas más frecuentes sobre PROPS Preguntas más frecuentes sobre PROPS 1. Qué es un modelo? Un modelo es un marco común para toda la organización. Está alineado con los estándares de gestión de proyectos, como PMBOK, ISO10006, ISO9000

Más detalles

Metodología básica de gestión de proyectos. Octubre de 2003

Metodología básica de gestión de proyectos. Octubre de 2003 Metodología básica de gestión de proyectos Octubre de 2003 Dentro de la metodología utilizada en la gestión de proyectos el desarrollo de éstos se estructura en tres fases diferenciadas: Fase de Éjecución

Más detalles

CAPITULO 4. Requerimientos, Análisis y Diseño. El presente capítulo explica los pasos que se realizaron antes de implementar

CAPITULO 4. Requerimientos, Análisis y Diseño. El presente capítulo explica los pasos que se realizaron antes de implementar CAPITULO 4 Requerimientos, Análisis y Diseño El presente capítulo explica los pasos que se realizaron antes de implementar el sistema. Para esto, primero se explicarán los requerimientos que fueron solicitados

Más detalles

Unidad VI: Supervisión y Revisión del proyecto

Unidad VI: Supervisión y Revisión del proyecto Unidad VI: Supervisión y Revisión del proyecto 61. Administración de recursos La administración de recursos es el intento por determinar cuánto, dinero, esfuerzo, recursos y tiempo que tomará construir

Más detalles

NOTAS TÉCNICAS SOBRE EL SIT: Documentos de Gestión

NOTAS TÉCNICAS SOBRE EL SIT: Documentos de Gestión NOTAS TÉCNICAS SOBRE EL SIT: Documentos de Gestión Introducción...2 Tipos de documentos...2 Datos de Cabecera...3 Nuevo Documento... 3 Modificar Documento... 4 Añadir, modificar y eliminar Artículos...5

Más detalles

El Software. Es lo que se conoce como el ciclo de vida del software.

El Software. Es lo que se conoce como el ciclo de vida del software. El Software Hace referencia a los programas y toda la información asociada y materiales necesarios para soportar su instalación, operación, reparación, y mejora. Para construir un nuevo elemento software

Más detalles

GUÍAS. Módulo de Diseño de software SABER PRO 2013-2

GUÍAS. Módulo de Diseño de software SABER PRO 2013-2 GUÍAS Módulo de Diseño de software SABER PRO 2013-2 GUÍAS Módulo de diseño en ingeniería El diseño de productos tecnológicos (artefactos, procesos, sistemas e infraestructura) está en el centro de la naturaleza

Más detalles

Las diez cosas que usted debe saber sobre las LICENCIAS de los derechos de Propiedad Industrial e Intelectual

Las diez cosas que usted debe saber sobre las LICENCIAS de los derechos de Propiedad Industrial e Intelectual Las diez cosas que usted debe saber sobre las LICENCIAS de los derechos de Propiedad Industrial e Intelectual 1.- Qué se entiende por Transferencia de Tecnología?. La transferencia de tecnología es el

Más detalles