Técnica para reusar artefactos de análisis y diseño en el modelamiento de software

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

Download "Técnica para reusar artefactos de análisis y diseño en el modelamiento de software"

Transcripción

1 Revista de Investigación ULASALLE, Rev Inv ULASALLE, Número 1, 2012 (67-78) Universidad La Salle Arequipa, Perú Técnica para reusar artefactos de análisis y diseño en el modelamiento de software 1 Percy Oscar Huertas Niquén Universidad La Salle Arequipa, Perú 2 Juan Lazo Lazo Laboratorio de Inteligencia Computacional Aplicada Río de Janeiro, Brasil Resumen Una de las infraestructuras de soporte son los artefactos de software, cuya concepción permite llegar a comprender, en su totalidad, la lógica del negocio del problema a resolver. El versionamiento se comporta como un repositorio de documentos con información útil para el personal que está modelando un nuevo sistema de información. Estos documentos también contribuyen al aprendizaje por medio de la consulta de activos que incluyan ejemplos y material de formación para entender y aplicar la lógica del negocio. El presente trabajo de investigación propone una técnica que permite conseguir la reutilización de los artefactos de software de manera que contribuyan en la construcción de un nuevo producto. Esta técnica implementa un procedimiento de acción que permite utilizar aquellos componentes que pueden servir de base para la conceptualización de productos de software nuevos. Palabras clave: reuso, diseño en modelamiento, software. Cuando se construyen productos de desarrollo de software, estos se encuentran basados en un proyecto de desarrollo que contienen procesos que deben ser respetados para lograr productos de calidad (Pressman, 2005; Sommerville, 2005). Cuando se obedecen estos procesos, el desarrollo se torna fácil en todo el ciclo, la veri cación y control de la calidad aumentan la con anza del producto. Por otro lado, se tiene que pensar continuamente en 1 Lic. en Estadística de la Universidad San Martín de Porres. Maestría en Ciencias de la Computación por la Universidad de Chile. Magíster en Ingeniería de Sistemas con Mención en Ingeniería de Software por la Universidad Nacional de San Agustín. Es Director de la Carrera de Ingeniería Informática de la Universidad La Salle. Correspondencia a -67-

2 una mejora de procesos para proporcionar bene cios a la organización, como por ejemplo, reducción de costos, incremento de la productividad, mejora de la calidad, satisfacción del cliente y, lo más importante, lograr un mayor nivel competitivo (Pressman, 2005; Sommerville, 2005). Sin embargo, los proyectos de mejora de procesos requieren de un gran esfuerzo humano, son largos en su ejecución y, por consiguiente, muy costosos (Pressman, 2005). Estos proyectos son críticos para la organización que los aborda, puesto que implican un cambio en su proceso de producción, con el n de lograr una mayor productividad y calidad de los productos que elaboran (Sommerville, 2005). Actualmente, se puede decir que la de nición de procesos está en un nivel poco maduro (Medina, 2010). Por consiguiente, la tarea de de nir procesos es difícil y costosa puesto que cada vez que se aborda la de nición de un nuevo proceso se parte de cero. Por otro lado, el despliegue de los procesos de nidos, constituye la tarea más desa ante a la que una organización se enfrenta (Medina, 2010). Una posible solución a este problema es elaborar una técnica que permita reutilizar los artefactos de proyectos de software en nuevos proyectos de desarrollo de software, basados en la experiencia de las personas que han hecho posible las construcciones pasadas. La elaboración y nalización de los proyectos de desarrollo de software ha generado una documentación histórica muy importante sobre cómo se han llevado a cabo sus procesos y de cómo han ido cambiando las versiones del producto. Antecedentes Medina (2010) menciona que emprender una mejora de procesos bene cia a la organización llevando a cabo un incremento de la productividad y la calidad. Para que esto ocurra, es necesario de un gran esfuerzo humano y de una gran paciencia para lograr los objetivos trazados. Mani esta que actualmente la de nición de procesos se encuentra poco madura y es por eso que plantea, de manera práctica, la formalización de la de nición y el despliegue del proceso. Su solución la orienta a la reutilización de los activos de procesos en nuevos proyectos y en donde propone el encapsulamiento del conocimiento, una estrategia corporativa para desplegar los procesos en toda la organización y una plataforma colaborativa para resolver el problema del equipo de trabajo. Gómez (2010) indica el auge que ha adquirido la ingeniería de software en los últimos años, otorgando especial atención a los procesos de desarrollo basándose en la idea de la calidad del producto la cual está relacionada directamente con la construcción del mismo. Ros (2009) presenta una propuesta de ingeniería de requisitos para líneas de productos que integra -68-

3 modelos de análisis del dominio y requisitos en lenguaje natural. Su propuesta se construye bajo tres esquemas claramente diferenciados: la reutilización de requisitos textuales (en donde incluye un modelo de procesos y una herramienta que lleva a cabo la integración); una descripción del modelamiento de la línea del producto; y, nalmente, el interés por la integración de modelos de ingeniería de software con especi caciones de requisitos en lenguaje natural. Ingeniería de Software La Ingeniería de Software es una disciplina que concierne a todos los aspectos de la producción de software que requiere un conjunto de conceptos, una metodología y un lenguaje propio. A este proceso también se le llama el ciclo de vida del software que comprende cuatro grandes fases: concepción, elaboración, construcción y transición. La concepción de ne el alcance del proyecto y desarrolla un caso de negocio. La elaboración de ne un plan del proyecto, especi ca las características y fundamenta la arquitectura. La construcción crea el producto y la transición trans ere el producto a los usuarios (Pressman, 2005). Actualmente se encuentra en una etapa de madurez el enfoque OO (Object oriented - Orientado a Objetos) como paradigma del desarrollo de sistemas de información. El OMG (Object Management Group, es un consorcio a nivel internacional que integra a los principales representantes de la industria de la tecnología de información OO). El OMG tiene como objetivo central la promoción, fortalecimiento e impulso de la industria OO. El OMG propone y adopta por consenso especi caciones entorno a la tecnología OO. Una de las especi caciones más importantes es la adopción en 1998 el Lenguaje de Modelado Uni cado o UML (del inglés Uni ed Modeling Language) como un estándar, que junto con el Proceso Uni cado están consolidando la tecnología OO (Pressman, 2005). Los proyectos de desarrollo de software se diferencian de los otros proyectos de ingeniería tradicional en la naturaleza lógica del producto software. Recordemos que el software se desarrolla, no se fabrica en un sentido clásico. En todos los proyectos de ingeniería la buena calidad se adquiere mediante un buen diseño, pero en el caso del software, la etapa de construcción incide pobremente en su calidad, no así en la construcción de hardware o de una obra civil. Así, no se puede gestionar un proyecto de desarrollo de software como si se tratara de un proyecto de fabricación (Sommerville, 2005; Bedini, 2005; Palacio & Ruata, 2011). La gestión del proyecto de software es el primer nivel del proceso de ingeniería de software, porque cubre todo el proceso de desarrollo. Para conseguir un proyecto de -69-

4 software fructífero se debe comprender el ámbito del trabajo a realizar, los riesgos en los que se puede incurrir, los recursos requeridos, las tareas a llevar a cabo, el esfuerzo (costo) a consumir y el plan a seguir. La gestión se puede resumir en las etapas que más adelante se detallarán y que se sustentan en los trabajos de Sommerville (2005) y Palacio y Ruata (2011). Técnica Propuesta Para llevar a cabo el desarrollo de la técnica, se analiza primero el artefacto original, y todo su versionamiento, y a partir de este se construirá el procedimiento para llevar a cabo la reutilización del mismo. Los artefactos presentados se exponen de manera independiente y la información contenida ayudará a proporcionar los elementos de juicio para lograr entender cuáles son los elementos a reutilizar, dentro del artefacto de software, para futuras aplicaciones. En la reutilización del artefacto y la concepción de la técnica, se contemplan tres casos: software con educciones similares, software con educciones diferentes y software con educciones medianamente similares. El software con educciones similares implica que son productos iguales y que sus necesidades son ligeramente diferentes. El software con educciones diferentes implica que los productos a construir son diferentes. Finalmente, se toca el tema del software con educciones medianamente similares, el cual implica la existencia de dos productos parecidos con una cantidad de artefactos parecidos. Etapa de análisis del sistema Educción, elicitación y especi cación de requerimientos La ingeniería de requerimientos se lleva a cabo con el artefacto denominado Documento de Educción de Requerimientos, el cual consiste en un conjunto de tablas que permiten recoger el conocimiento inicial del producto a construir. En ella se traduce las expectativas del cliente con respecto al producto a desarrollar. El procedimiento para la reutilización es el siguiente: 1. Marcar en rojo toda la plantilla de requerimientos. 2. Agregar, con color negro, los conceptos que se inserten en el nombre del requerimiento hasta formar el requerimiento deseado. Si los conceptos coinciden, reutilizar el 100% del concepto que se encuentra en la plantilla. -70-

5 3. Eliminar el nombre del antiguo autor e insertar el nuevo. Si el autor es el mismo reutilizar el 100% del mismo. 4. Eliminar el nombre de la fuente e insertar el nombre de la nueva fuente. Si la fuente es la misma reutilizar el 100% del campo de la plantilla. 5. Agregar, con color negro, los conceptos de la nueva descripción utilizando los que se encuentran en la plantilla. Si el caso es el mismo reutilizar el 100% del campo de la plantilla. 6. Agregar, en color negro, los conceptos para el nuevo comentario utilizando aquellos que se encuentran en la plantilla. Si el caso es el mismo, reutilizar el 100% del campo de la plantilla. 7. Contabilizar la cantidad de cambios para formar el índice correspondiente. Casos esenciales de uso Los casos esenciales de uso se llevan a cabo con el artefacto denominado Documento de Análisis, el cual consiste en un conjunto de tablas que permiten recoger el conocimiento inicial del modelo del negocio visto por el analista de sistemas. En ella se traduce las expectativas del analista de sistema con respecto al modelo de negocio elicitado. El procedimiento para la reutilización es el siguiente: Se identi can los campos comunes y luego se lleva a cabo lo especi cado en el numeral A para casos de uso. Diagramas de casos esenciales de uso El diagrama de casos esenciales de uso se lleva a cabo con el artefacto denominado Documento de Análisis, el cual consiste en un conjunto de casos de uso que permiten recoger el modelo conceptual, en su etapa inicial, del modelo del negocio visto por el analista de sistemas. En ella se traduce las expectativas del analista de sistema con respecto a la modularización del sistema a construir. El procedimiento de reutilización, para los tres casos previstos, es el siguiente: Ambigüedades surgidas por la aplicación de la descomposición Cuando la estructura de los casos de uso se ve re ejada directamente en el código, de modo que el diseño de los casos de uso del sistema se parece a los -71-

6 casos de uso del usuario. Un síntoma común es encontrar al comportamiento de los objetos manipulando datos: esto es poco más que una estructura de datos encapsulada. Este tipo de diseño ayuda a perder la mayor parte de los bene cios y características de los objetos. El sistema duplica el comportamiento a través de los distintos controladores y el conocimiento de esta estructura de datos también es conocido por los demás controladores. La esencia del problema es que la descomposición funcional nos anima a pensar en el contexto de un comportamiento de alto nivel. Ambigüedades surgidas por el abuso de la abstracción Los objetos nacen de la abstracción. Un buen diseño es aquel que se basa en las abstracciones simples, haciendo de un problema complejo algo manejable. Así como los diseñadores utilizan la abstracción, otros integrantes del equipo de desarrollo de software también la pueden usar. Pero la abstracción puede llevar a problemas en los casos de uso. Comúnmente, los usuarios entienden los casos de uso, al principio, y posteriormente, se sienten perdidos con los casos de uso más abstractos. Ambigüedades surgidas por el uso de las interfaces grá cas del usuario Con todas las herramientas para diseñar interfaces grá cas de usuario que existen en estos días, muchos desarrolladores las están usando para ayudar a determinar los casos de uso. Esta lógica es atractiva. Una interfaz grá ca de usuario es concreta a un usuario, nos ayuda a no olvidar detalles; da al usuario una sensación de cómo se verá el sistema. Las interfaces grá cas de usuario son fáciles de prototipar ya que hacen demostraciones razonables para explicar la capacidad del futuro sistema. Al mostrar un prototipo de una interfaz grá ca de usuario a un usuario, parece que casi todo lo hace, y que lo único que queda son pocos detalles detrás de las escenas. Ambigüedades surgidas por el uso de plantillas de otros proyectos de desarrollo de software En muchas ocasiones insertamos, en el proyecto actual, plantillas de casos de uso de otros proyectos llevados a cabo. El problema con estos casos de uso es que no abordan directamente las necesidades de un usuario. Las necesidades reales del usuario son algo así como garantizar un formato consistente dentro de un documento. El problema con ir directamente al caso de uso del sistema es que se le niega la oportunidad de llegar a los casos de uso de otro sistema que se ocupe de lo mismo. -72-

7 Ambigüedades surgidas por el mal diseño de los casos de uso Cuando se plani ca la construcción de un sistema automatizado se prevé que los artefactos generados en las etapas iniciales sean los adecuados para la etapa de diseño. El defecto de los casos de uso, para esta etapa, implica que no existen los mecanismos adecuados para lograr determinar los comportamientos generales o especializados haciendo que el actor, relacionado con el caso de uso, viaje a través de la generalización y la especialización del caso de uso correspondiente. Ambigüedades surgidas por la arquitectura Otro problema importante corresponde a la arquitectura del sistema que puede dar lugar a una mala interpretación de los casos de uso. Esto, debido a la mala interpretación que se lleva a cabo con respecto a la arquitectura del software. Dichas arquitecturas, típicamente, exhiben encapsulación pobre y de acoplamiento excesivo, y una inadecuada distribución de la inteligencia de la demanda entre las clases. Ambigüedades surgidas por los escenarios Esta ambigüedad surge por la poca claridad que existe entre el concepto de caso de uso y escenario. Ambigüedades surgidas por la educción de requerimientos Esta es la primera etapa de la ingeniería de requerimientos. En ella se toma contacto con el cliente para empezar a entender el problema que se tiene que resolver. Generalmente, los clientes no entienden de computación o informática y proporcionan sus ideas de manera desordenada pensando que el ingeniero de sistemas puede entenderlas a cabalidad. Ambigüedades surgidas por la elicitación de requerimientos Esta es la segunda etapa de la ingeniería de requerimientos. El ingeniero de sistemas tiene en mente toda la problemática del problema a resolver; incluso se arriesga a representar el problema con los primeros casos de uso. Después de varias iteraciones concibe el documento de elicitación de requerimientos. A partir de este artefacto se diseñan los casos de uso posteriores. Las fallas de redacción, ortografía, sintaxis y semántica conllevan a una mala interpretación de los casos de uso. -73-

8 Modelamiento conceptual El modelamiento conceptual (que se lleva a cabo con el artefacto denominado Documento de Análisis), consiste en un conjunto de entidades que permiten recoger el conocimiento más estructurado del producto a construir. En ella se traduce las primeras expectativas del diseñador del sistema con respecto al modelo de negocio. El procedimiento para la reutilización es el siguiente: 1. Identi car todas las entidades comunes con la concepción del nuevo sistema y reutilizarlos si es necesario, caso contrario agregar las nuevas entidades representativas. 2. Eliminar las entidades que no corresponden a la construcción del nuevo sistema. 3. Identi car las relaciones comunes y dejarlas en el grá co correspondiente, caso contrario eliminarlas. 4. Versionar el nuevo documento. 5. Llevar a cabo la métrica de contabilización de elementos. Diagramas de secuencias El diagrama de secuencias, que se lleva a cabo con el artefacto denominado Documento de Análisis, tiene que ver con la forma en que responde el sistema cuando el usuario lo ejecuta y lo usa para sus necesidades. En ella se traduce las primeras expectativas del diseñador del sistema con respecto al punto de vista de la construcción del código fuente. El procedimiento para la reutilización es el siguiente: 1. Identi car los mensajes que el usuario le proporciona al sistema, si estos coinciden reutilizarlo al 100%, caso contrario agregar, en color diferente, los nuevos mensajes del sistema. 2. Identi car las respuestas del sistema, si estas coinciden reutilizar al 100%, caso contrario insertar las nuevas respuestas del sistema. 3. Eliminar los mensajes y respuestas que no corresponden al modelo de negocio del nuevo sistema a construir. -74-

9 4. Contabilizar los cambios. Etapa de diseño del sistema Casos reales de uso Los casos reales de uso se llevan a cabo con el artefacto denominado Documento de Diseño, los cuales consisten en expresar, en un lenguaje mucho más formal y orientado a los desarrolladores del producto. Es la primera forma de migrar al código fuente. En ella se traduce las primeras expectativas del implementador del sistema con respecto al punto de vista de la especi cación de requerimientos de software. Su reutilización es similar al de los casos de uso esenciales. Interfaces de usuario Las interfaces de usuario se llevan a cabo con el artefacto denominado Documento de Diseño, los cuales consisten en expresar, en un lenguaje básico las funcionalidades del sistema a emplear por parte del usuario nal. En ella se traduce las primeras expectativas del usuario nal por entender cómo el sistema solucionará sus problemas; además de brindarle un espectro nal de todo el sistema mandado a construir. El procedimiento para la reutilización en cada uno de las interfaces de usuario es el siguiente: 1. Llevar a cabo el análisis de componentes de cada uno de las interfaces de usuario. Si el objetivo es similar entonces reutilizar el componente; luego analizar el contenido del componente para saber si los ítems son los mismos a considerar. Si esto es verdad, reutilizar todo el componente y su contenido, caso contrario agregar los nuevos conceptos al contenido del componente. 2. Llevar a cabo un análisis, dentro de la pantalla, de la posición donde se encuentra el componente. Si la posición es correcta, tomarla como tal, caso contrario desplazar a la nueva posición. 3. Llevar a cabo un análisis de la densidad de la interfaz de usuario. Si la densidad es alta, siete más menos dos objetos, diseñar una nueva interfaz de usuario reutilizando aquellos elementos que son necesarios. Insertarlos dentro del modelo de navegabilidad correspondiente. 4. Contabilizar las métricas correspondientes. -75-

10 Modelo de navegabilidad El modelo de navegabilidad se lleva a cabo con el artefacto denominado Documento de Diseño, el cual consiste en expresar, mediante un diagrama de precedencias, la forma como aparecerán o desaparecerán las interfaces de usuario a medida que los use el usuario nal. En ella se traduce el recorrido que llevarán a cabo las expectativas del usuario nal por solucionar los problemas de la organización que están re ejados en el sistema computacional. El procedimiento para la reutilización es el siguiente: 1. Analizar el modelo de navegabilidad original comparando con el nuevo modelo propuesto. 2. Si existen componentes comunes, reutilizarlos; caso contrario confeccionar uno nuevo para luego insertarlo en el nuevo modelo. 3. Contabilizar los cambios efectuados. Diagrama de diseño de clases El diagrama de clases se lleva a cabo con el artefacto denominado Documento de Análisis, el cual consiste en expresar, en un conjunto de entidades, la forma de nitiva de las relaciones y asociaciones de los objetos en el sistema a construir. En ella se traduce las expectativas de nitivas del implementador del sistema con respecto al punto de vista de la especi cación de requerimientos de software y elicitación de requerimientos. El procedimiento para la reutilización, en los tres casos contemplados, es el siguiente: cuando se hace el análisis y diseño de sistemas y se emplea la herencia, encontraremos algunas ambigüedades tanto en herencia simple, como en herencia múltiple. La herencia simple presenta una debilidad en la clase base. La clase base de la cual se va a heredar desconoce la cantidad de hijos que tendrá por consiguiente cualquier cambio realizado en dicha clase podría ocasionar problemas sobre todo en aplicaciones que usan un gran número de clases. En este caso diremos que la clase base es una clase débil. Esquema de las bases de datos El esquema de las bases de datos se lleva a cabo con el artefacto denominado Documento de Diseño, los cuales consisten en expresar, en un conjunto de entidades, la forma de nitiva de las relaciones y asociaciones de los objetos en el sistema a construir en forma física. En ella se traduce las -76-

11 expectativas de nitivas del implementador del sistema con respecto al punto de vista de la especi cación de requerimientos de software y elicitación de requerimientos con respecto a las consultas del usuario al sistema. El procedimiento para la reutilización es el siguiente: 1. Llevar a cabo un análisis de las entidades participantes, si estas son necesarias reutilizarlos, caso contrario eliminarlas e insertar nuevas entidades. 2. Si la entidad es reutilizada, analizar las claves primarias. Si estas son necesarias, reutilizarlos; caso contrario eliminar la antigua e insertar la nueva clave primaria. 3. Si la entidad es reutilizada, analizar las claves secundarias. Si estas son necesarias, reutilizarlos; caso contrario eliminar la antigua e insertar la nueva clave secundaria. 4. Llevar a cabo un análisis de la cardinalidad de las relaciones, si coincide, reutilizarlo; caso contrario eliminar la antigua e insertar el nuevo concepto. 5. Analizar las relaciones en forma general para entender que las conectividades tienen lógica. Si coinciden reutilizarlos; caso contrario insertar las nuevas asociaciones. 6. Llevar a cabo las métricas del caso. Conclusiones La técnica propuesta nos permite reutilizar, eliminar e insertar componentes nuevos sobre el producto destino, logrando así reutilizar los activos de la documentación histórica del producto de software desarrollado. Se propone, encaminar la reutilización bajo un conjunto de patrones según las fases de construcción del producto. Así, de nir el patrón educción de requerimientos nos permite encaminar el modelo de negocio de manera clara permitiendo una reutilización con mayor análisis de criterio. Las fases de construcción proporcionan patrones de trabajo muy orientados a lo que se desea reutilizar. La estrategia de representación se encuentra basada en separar claramente la especi cación del artefacto a reutilizar, en el proyecto origen, de la -77-

12 implementación del mismo en el proyecto destino. Si el producto inicial tuvo un modelamiento de calidad, el producto destino también lo tendrá. Estadísticamente se demuestra que la mayoría de los artefactos reutilizados o que se reutilizan son más del 94% de sus componentes. Referencias Bedini, A. (2005).Gestión de proyectos de software. Chile: Universidad Santa María Gómez, A. (2010). Metamodelado de procesos de desarrollo software y sistemas multiagente. Tesis para optar el grado de doctor con mención en doctorado europeo. Universidad de Vigo. España. Medina, F. (2010). Marco metodológico para la mejora de la e ciencia de uso de los procesos software. Tesis para optar el grado de doctor. Universidad Carlos III de Madrid. España. Palacio, J. & Ruata, C. (2011). Scrum Manager Gestión de Proyectos. s.l.e.: Safe Creative. Pressman, R. (2005). Ingeniería del software: Un enfoque práctico. 6ta ed. México: McGraw Hill. Ros, J. (2009). Una propuesta de gestión integrada de modelos y requisitos en líneas de productos software. Tesis para optar el grado de doctor. Universidad de Murcia. España. Sommerville, I. (2005). Ingeniería del Software. 7ma ed. México: Prentice Hall. -78-

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

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

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

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

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

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

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

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

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

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

2.1 Ingeniería de Software

2.1 Ingeniería de Software Capítulo 2 Marco Teórico Se pretende desarrollar un software que pueda ser aplicado como una herramienta útil para la administración de una empresa. Es necesario tener en cuenta que, en todo desarrollo

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

Teórica 2 64 Laboratorio 1 32 Resolución de problemas 0.5 16 Ejemplos prácticos en clase 0.5 16 Suma 4 128

Teórica 2 64 Laboratorio 1 32 Resolución de problemas 0.5 16 Ejemplos prácticos en clase 0.5 16 Suma 4 128 CÓDIGO ASIGNATURA 626 DEPARTAMENTO: Ingeniería e Investigaciones Tecnológicas ASIGNATURA: Construcción de sistemas II Ingeniería en Informática 2011 OBJETIVOS Estudiar y modelizar requerimientos de sistemas

Más detalles

El Proceso Unificado Rational para el Desarrollo de Software.

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

Más detalles

Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI

Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI Universidad Católica Andrés Bello Ingeniería en Informática Metodologías Ágiles de Gestión de Proyectos TI MODELO Y HERRAMIENTA DE AUTOMATIZACIÓN PARA AGREGAR VALOR A LOS PRINCIPIOS ÁGILES DE DESARROLLO

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

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él.

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él. PROCESOS SOFTWARE MOTIVACIÓN? Con independencia de la metodología o modelo implementado, es común la estrategia para la mejora continua de la calidad, basada en el Círculo de Deming o Plan, Do, Check,

Más detalles

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS

LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS ELECTRÓNICOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS LINEAMIENTOS GENERALES PARA LA IMPLEMENTACIÓN DE PROCESOS Ministerio de Tecnologías de la Información y las Comunicaciones Programa de Gobierno

Más detalles

Pontificia Universidad Católica Argentina

Pontificia Universidad Católica Argentina Carrera : Ingeniería Informática Pontificia Universidad Católica Argentina PROGRAMA DE INGENIERÍA DE SOFTWARE I 2010 Ubicación en el Plan de Estudios : 3 er Año, cuatrimestral Carga Horaria : 8 hs / semana

Más detalles

Cristian Blanco www.cristianblanco.es

Cristian Blanco www.cristianblanco.es 3.1.- INTRODUCCIÓN Para realizar el desarrollo de cualquier proyecto de software es necesario llevar una sistemática de trabajo, que nos asegure el éxito del mismo. Lo que tenemos que evitar, en el desarrollo

Más detalles

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar

MODELADO DE OBJETOS. {brossi,pbritos,rgm}@itba.edu.ar MODELADO DE OBJETOS Bibiana ROSSI, Paola BRITOS y Ramón GARCIA MARTINEZ, CAPIS - Centro de Actualizacion Permanente en Ingeniería de Software Escuela de Posgrado. ITBA. 0. INTRODUCCION {brossi,pbritos,rgm}@itba.edu.ar

Más detalles

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

Programa de la asignatura Curso: 2009 / 2010 ANÁLISIS E INGENIERÍA DEL SOFTWARE (1296)

Programa de la asignatura Curso: 2009 / 2010 ANÁLISIS E INGENIERÍA DEL SOFTWARE (1296) Programa de la asignatura Curso: 2009 / 2010 ANÁLISIS E INGENIERÍA DEL SOFTWARE (1296) PROFESORADO Profesor/es: MARIA BELEN VAQUERIZO GARCIA - correo-e: belvagar@ubu.es FICHA TÉCNICA Titulación: INGENIERÍA

Más detalles

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio M. Teresa García 1, Mercedes Ruiz 1 y Cristina Vicente-Chicote 2 1 Departamento de Lenguajes y Sistemas Informáticos Universidad

Más detalles

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1 IWG-101: Introducción a la Ingeniería Departamento de Informática, UTFSM 1 Introducción a UML Historia Potencialidades Diagramas soportados UML en el proceso de desarrollo de SW. Introducción a UML Necesidad

Más detalles

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos Tema 13 Metodologías en el desarrollo de Sistemas de Software Prof. Oscar Adolfo Vallejos Desarrollo de Sistemas de Software Objetivo Conceptos en el contexto más amplio de Software e Ingeniería de Software

Más detalles

Ingeniería del Software II

Ingeniería del Software II Ingeniero Técnico en Informática de Gestión Exámenes de Recuperación Curso 2011/12-2012/13 Profesor: Francisco Luis Gutiérrez Vela Departamento de Lenguajes y Sistemas Informáticos ! Profesor encargado:

Más detalles

INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO IBEROTEC SEMESTRE ACADÉMICO: 2014-II SÍLABO UNIDAD DIDÁCTICA : ANÁLISIS Y DISEÑO DE SISTEMAS INFORMÁTICOS

INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO IBEROTEC SEMESTRE ACADÉMICO: 2014-II SÍLABO UNIDAD DIDÁCTICA : ANÁLISIS Y DISEÑO DE SISTEMAS INFORMÁTICOS INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO IBEROTEC SEMESTRE ACADÉMICO: 201-II 1. DATOS GENERALES SÍLABO UNIDAD DIDÁCTICA : ANÁLISIS Y DISEÑO DE SISTEMAS INFORMÁTICOS MÓDULO : DESARROLLO DE SOFTWARE TIPO

Más detalles

GUÍA DOCENTE DE LA ASIGNATURA

GUÍA DOCENTE DE LA ASIGNATURA GUÍA DOCENTE DE LA ASIGNATURA G658 - Ingeniería del Software I Grado en Ingeniería Informática Obligatoria. Curso 3 Curso Académico 04-05 . DATOS IDENTIFICATIVOS Título/s Grado en Ingeniería Informática

Más detalles

Enseñando y Aprendiendo Programación Orientada a Objetos en los primeros cursos de Programación: la experiencia en la Universidad ORT Uruguay

Enseñando y Aprendiendo Programación Orientada a Objetos en los primeros cursos de Programación: la experiencia en la Universidad ORT Uruguay Enseñando y Aprendiendo Programación Orientada a Objetos en los primeros cursos de Programación: la experiencia en la Universidad ORT Uruguay Resumen Ing. Inés Kereki 1 Universidad ORT Uruguay e-mail:

Más detalles

Hacer Realidad BPM en su Organización ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN

Hacer Realidad BPM en su Organización ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN OBJETIVOS GENERALES 1. Identificar, diseñar, automatizar y habilitar la mejora continua de los procesos relacionados a la necesidad o proyecto

Más detalles

Secretaría de Docencia Dirección de Estudios Profesionales

Secretaría de Docencia Dirección de Estudios Profesionales I. IDENTIFICACIÓN DEL CURSO PROGRAMA DE ESTUDIOS POR COMPETENCIAS PROGRAMACIÓN ORIENTADA A OBJETOS Espacio Educativo: Facultad de Ingeniería Licenciatura: Ingeniería de Computación Área de docencia: Programación

Más detalles

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio Arturo Cepeda Pérez, Sergio Bravo Martín, Francisco José García Peñalvo Universidad de Salamanca, Facultad

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 11. Reutilización del software

Fundamentos de Ingeniería del Software. Capítulo 11. Reutilización del software Fundamentos de Ingeniería del Software Capítulo 11. Reutilización del software Reutilización del software. Estructura 1. Reutilización del software 2. Beneficios de la reutilización 3. Dificultades para

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

Ingeniería de software orientado a agentes

Ingeniería de software orientado a agentes Ingeniería de software orientado a agentes ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de software orientado a agentes Curso 2014/2015 1 / 52 Índice 1 Ingeniería de software

Más detalles

CARTA DESCRIPTIVA (FORMATO MODELO EDUCATIVO UACJ VISIÓN 2020)

CARTA DESCRIPTIVA (FORMATO MODELO EDUCATIVO UACJ VISIÓN 2020) CARTA DESCRIPTIVA (FORMATO MODELO EDUCATIVO UACJ VISIÓN 2020) I. Identificadores de la asignatura Instituto: IIT Modalidad: Presencial Departamento: Materia: Eléctrica y Computación Programación II Créditos:

Más detalles

TEMA 1.-Programación orientada a objetos (POO) Objetivo

TEMA 1.-Programación orientada a objetos (POO) Objetivo CURSO DE UML Dotar al alumno de los fundamentos de la programación orientada a objetos (POO, a partir de ahora), definir las características básicas del lenguaje de modelado unificado (Unified Modeling

Más detalles

Diseño de Procesos al Servicio de la Gestión

Diseño de Procesos al Servicio de la Gestión Gestión y servicios Tecnológicos Ltda. Diseño de Procesos al Servicio de la Gestión www.gyst.cl info@gyst.cl Gestión y servicios Tecnológicos Ltda. En Algunas Empresas... En numerosos proyectos de variada

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

ARQUITECTURA DE SOFTWARE

ARQUITECTURA DE SOFTWARE ARQUITECTURA DE SOFTWARE Introducción n a la Arquitectura de Software (sistemas) Requisitos de calidad Documento de Diseño RTFS-Método del control de diseño Introducción n al Diseño o de la interfaz Humano/Computador

Más detalles

Ingeniería de Software: Parte 2

Ingeniería de Software: Parte 2 Ingeniería de Software: Parte 2 Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes.

Más detalles

Enterprise Analyst: Taller de Bautizo

Enterprise Analyst: Taller de Bautizo Enterprise Analyst: Taller de Bautizo Metas Entender la Necesidad de Ejecutar los Modelos Desarrollar un caso usando UML tradicional Identificar los problemas de UML Conocer la Herramienta Enterprise Analyst

Más detalles

Plan de curso Sílabo-

Plan de curso Sílabo- a. Asignatura Plan de curso Sílabo- b. Nro. Créditos c. Código d. Horas de trabajo directo con el docente e. Horas de trabajo autónomo del estudiante Refinamiento en Producción de Software 3 3 6 f. Del

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

ASI. Análisis del Sistema de Información

ASI. Análisis del Sistema de Información ASI Análisis del Sistema de Información 1 ASI Análisis del Sistema de Información Introducción Objetivo Obtención de una especificación detallada del Sistema Información a través de: Catálogo de Requisitos

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 12. Herramientas CASE

Fundamentos de Ingeniería del Software. Capítulo 12. Herramientas CASE Fundamentos de Ingeniería del Software Capítulo 12. Herramientas CASE Herramientas CASE Estructura 1. Introducción 2. Características deseables 3. Componentes de una herramienta CASE 4. Taxonomías de herramientas

Más detalles

CAPÍTULO 1 INTRODUCCIÓN, HIPÓTESIS Y OBJETIVOS

CAPÍTULO 1 INTRODUCCIÓN, HIPÓTESIS Y OBJETIVOS CAPÍTULO 1 INTRODUCCIÓN, HIPÓTESIS Y OBJETIVOS 1 INTRODUCCIÓN 1.1 Justificación Esta investigación está motivada por el interés en lograr una mejor comprensión del papel que desempeña la creatividad dentro

Más detalles

CARTA DESCRIPTIVA 1. PRESENTACIÓN PLAN DE ESTUDIOS: IS02 CRÉDITOS 5 CÓDIGO DEL CURSO: IS020 NIVEL: VI ÁREA O COMPONENTE DE FORMACIÓN: Específica

CARTA DESCRIPTIVA 1. PRESENTACIÓN PLAN DE ESTUDIOS: IS02 CRÉDITOS 5 CÓDIGO DEL CURSO: IS020 NIVEL: VI ÁREA O COMPONENTE DE FORMACIÓN: Específica FACULTAD: Ingenierías PROGRAMA: Ingeniería de sistemas NOMBRE DEL CURSO: CARTA DESCRIPTIVA Ingeniería de Software 1. PRESENTACIÓN PLAN DE ESTUDIOS: IS02 CRÉDITOS 5 CÓDIGO DEL CURSO: IS020 NIVEL: VI ÁREA

Más detalles

plataforma específica de desarrollo, limitaciones del recurso físico disponible, limitaciones del sistema a actualizar, etc).

plataforma específica de desarrollo, limitaciones del recurso físico disponible, limitaciones del sistema a actualizar, etc). REVISIÓN CONCEPTOS, METODOLOGÍAS Y HERRAMIENTAS SOPORTE EN INGENIERÍA MARLON MÚJICA Estudiante de Ingeniería de Sistemas Universidad Industrial de Santander mujica@cidlisuis.org COLOMBIA EDWIN LOGREIRA

Más detalles

Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo

Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes

Más detalles

Programación del curso

Programación del curso Ingeniería Software 4º Físicas Programación del curso José M. Drake (drakej@unican.es) Patricia López Martínez ( lopezpa@unican.es ) Computadores y Tiempo Real Santander, 2008 Ingeniería de Programación

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

Ingeniería de software

Ingeniería de software Ingeniería de software MSC-0102 Nombre de la asignatura: Ingeniería de Software Línea de trabajo: Asignatura básica Tiempo de dedicación del estudiante a las actividades de: DOC TIS TPS Horas totales Créditos

Más detalles

UNIVERSIDAD NACIONAL FEDERICO VILLARREAL FACULTAD DE INGENIERÍA ELECTRÓNICA E INFORMÁTICA SÍLABO

UNIVERSIDAD NACIONAL FEDERICO VILLARREAL FACULTAD DE INGENIERÍA ELECTRÓNICA E INFORMÁTICA SÍLABO SÍLABO ASIGNATURA: INGENIERIA DE SISTEMAS DE INFORMACION II CÓDIGO: 8B0023 1. DATOS GENERALES 1.1 DEPARTAMENTO ACADÉMICO : Ingeniería Informática Electrónica 1.2 ESCUELA PROFESIONAL : Ingeniería Informática

Más detalles

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Fernández Taurant, Juan Pablo Marciszack, Marcelo Martín Universidad Tecnológica Nacional, Facultad Regional

Más detalles

Tecnología VoIP integrada en Sistemas de Emergencia Policiales

Tecnología VoIP integrada en Sistemas de Emergencia Policiales Tecnología VoIP integrada en Sistemas de Emergencia Policiales Mariela E. Rodriguez 1, José Farfan 2, & José V. Zapana 3 Cátedra de Modelos de Desarrollo de Programas y Programación Concurrente / Facultad

Más detalles

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

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

CARTA DESCRIPTIVA Código: FO-MI-108 Versión: 3 Fecha: 25-10-2013

CARTA DESCRIPTIVA Código: FO-MI-108 Versión: 3 Fecha: 25-10-2013 CARTA DESCRIPTIVA Código: FO-MI-108 Versión: 3 Fecha: 25-10-2013 1. PRESENTACIÓN FACULTAD: Ingenierías PROGRAMA: Ingeniería de sistemas NOMBRE DEL CURSO: Ingeniería de Software PLAN DE ESTUDIOS: IS01 CRÉDITOS

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

UNIVERSIDAD PONTIFICIA DE SALAMANCA DOCTORADO EN INGENIERÍA INFORMÁTICA

UNIVERSIDAD PONTIFICIA DE SALAMANCA DOCTORADO EN INGENIERÍA INFORMÁTICA UNIVERSIDAD PONTIFICIA DE SALAMANCA Campus de Madrid Facultad de Informática DOCTORADO EN INGENIERÍA INFORMÁTICA Programa en Ingeniería del Software BIENIO 2003-2005 ASIGNATURA: Diseño Avanzado de Sistemas

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

Propuesta de un modelo basado en redes neuronales para la detección de riesgo crediticio

Propuesta de un modelo basado en redes neuronales para la detección de riesgo crediticio Revista de Investigación ULASALLE, Rev Inv ULASALLE, Número 1, 2012 (55-64) Universidad La Salle Arequipa, Perú Propuesta de un modelo basado en redes neuronales para la detección de riesgo crediticio

Más detalles

1.- DATOS DE LA ASIGNATURA. Nombre de la asignatura: Fundamentos de Ingeniería de Software. Ingeniería en Sistemas Computacionales.

1.- DATOS DE LA ASIGNATURA. Nombre de la asignatura: Fundamentos de Ingeniería de Software. Ingeniería en Sistemas Computacionales. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: (Créditos) SATCA 1 Fundamentos de Ingeniería de Software Ingeniería en Sistemas Computacionales SCC-1007 2-2-4 2.- PRESENTACIÓN

Más detalles

implantación Fig. 1. Ciclo de vida tradicional

implantación Fig. 1. Ciclo de vida tradicional 1. Ciclo de vida tradicional de los sistemas de software En ingeniería de software, la descripción tradicional del ciclo de vida del software está basada en un modelo conocido como el modelo de cascada

Más detalles

MANTENIMIENTO DE SOFTWARE

MANTENIMIENTO DE SOFTWARE MANTENIMIENTO DE SOFTWARE Definición de Mantenimiento El estándar IEEE 1219 [IEEE, 1993] define el Mantenimiento del Software como la modificación de un producto software después de haber sido entregado

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S1 Francisco Ruiz, Macario Polo Grupo Alarcos Dep. de Informática ESCUELA SUPERIOR DE INFORMÁTICA UNIVERSIDAD DE CASTILLA-LA MANCHA http://alarcos.inf-cr.uclm.es/doc/mso/ Ciudad

Más detalles

Analista Programador PL/SQL Oracle 11g

Analista Programador PL/SQL Oracle 11g Titulación certificada por EUROINNOVA BUSINESS SCHOOL Analista Programador PL/SQL Oracle 11g Analista Programador PL/SQL Oracle 11g Duración: 360 horas Precio: 300 * Modalidad: Online * Materiales didácticos,

Más detalles

UML. Lenguaje de Modelado Unificado

UML. Lenguaje de Modelado Unificado Lenguaje de Modelado Unificado Concepto de Reseña Histórica Características Estándares que conforman Modelo Relacional con Ventajas Críticas Concepto de (Unified( Modeling language) Es un lenguaje usado

Más detalles

Herramientas de Desarrollo de Software: Hacia la Construcción de una Ontología

Herramientas de Desarrollo de Software: Hacia la Construcción de una Ontología Herramientas de Desarrollo de Software: Hacia la Construcción de una Ontología Lornel A. Rivas 1,2, María Pérez 2, Luis E. Mendoza 2, y Anna Grimán 2 1 Gerencia de Investigación, Instituto Nacional de

Más detalles

Gestión de. Requisitos previos. Carácter ECTS. Periodo NINGUNOO. Idiomas en Inglés. Departamento. Ciencias de. Presentación. Despacho y.

Gestión de. Requisitos previos. Carácter ECTS. Periodo NINGUNOO. Idiomas en Inglés. Departamento. Ciencias de. Presentación. Despacho y. = =drð^=al`bkqb qfqri^`flkbp=ab=do^al= TITULACIÓN: INGENIERÍA DE SISTEMAS DE INFORMACIÓN CURSO: Segundo ASIGNATURA: Ingeniería del Software I Nombre del Módulo o Materia al que pertenece la asignatura.

Más detalles

Introducción. Primera aproximación a los conceptos Orientados a Objetos

Introducción. Primera aproximación a los conceptos Orientados a Objetos Desarrollo de juegos como base para la compresión de temas fundamentales de la programación orientada a objetos Ponencia Aprendizaje y currículo HÉCTOR FABIO CADAVID RENGIFO ESCUELA COLOMBIANA DE INGENIERÍA

Más detalles

Tema 1 Introducción a la Ingeniería de Software

Tema 1 Introducción a la Ingeniería de Software Tema 1 Introducción a la Ingeniería de Software Curso Ingeniería de Software UMCA Profesor Luis Gmo. Zúñiga Mendoza 1. Software En la actualidad todo país depende de complejos sistemas informáticos. Podemos

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

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

Analista Programador PL/SQL Oracle 11g

Analista Programador PL/SQL Oracle 11g TITULACIÓN DE FORMACIÓN CONTINUA BONIFICADA EXPEDIDA POR EL INSTITUTO EUROPEO DE ESTUDIOS EMPRESARIALES Analista Programador PL/SQL Oracle 11g Duración: 360 horas Precio: 0 * Modalidad: Online * hasta

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

14. Ingeniería de software. Ing. Alejandro Adorjan

14. Ingeniería de software. Ing. Alejandro Adorjan 14. Ing. Alejandro Adorjan : un enfoque en ingeniería de requerimientos Introducción La ingeniería de software es una disciplina que estudia la aplicación de la teoría, el conocimiento y la práctica de

Más detalles

Tema 1 Introducción a los Sistemas Basados en el Conocimiento

Tema 1 Introducción a los Sistemas Basados en el Conocimiento Tema 1 Introducción a los Sistemas Basados en el Conocimiento Sistemas Basados en el Conocimiento Grado en Ingeniería Informática 1 Referencias Ingeniería del Conocimiento. A. Gómez, N. Juristo, C. Montes,

Más detalles

Programación Orientada a Objetos: Lenguajes, Metodología y Herramientas Master de Computación

Programación Orientada a Objetos: Lenguajes, Metodología y Herramientas Master de Computación M AS T Programación Orientada a Objetos: Lenguajes, Metodología y Herramientas Master de Computación PROGRAMACION ORIENTADA A OBJETOS J.M. Drake 1 LA CRISIS DEL SOFTWARE. Conjunto de tópicos relacionados

Más detalles

Estándares y Métricas de Software

Estándares y Métricas de Software PROGRAMA DE ESTUDIO Programa Educativo: Área de Formación : Licenciatura en Tecnología de Información Estándares y Métricas de Software Horas teóricas: 2 Horas prácticas: 4 Total de Horas: 8 Total de créditos:

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

Curso Taller de Arquitectura de Software usando UML

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

Más detalles

Tema 8º: Aspectos prácticos

Tema 8º: Aspectos prácticos Tema 8º: Aspectos prácticos Gestión y planificación Administración de personal Gestión de versiones Reutilización Control de calidad del software Documentación Herramientas Temas especiales Las ventajas

Más detalles

ANÁLISIS Y DISEÑO DE UN PORTAL DE VENTA DE LIBROS EDUCATIVOS

ANÁLISIS Y DISEÑO DE UN PORTAL DE VENTA DE LIBROS EDUCATIVOS INGENIERIA DE SOFTWARE Trabajo Final de Carrera ANÁLISIS Y DISEÑO DE UN PORTAL DE VENTA DE LIBROS EDUCATIVOS Jordi Cid Rodríguez - ETIG - Consultor: José Antonio Raya Martos Septiembre 2011 Objetivo El

Más detalles

Carrera: SCD-1011 SATCA 1 2-3-5

Carrera: SCD-1011 SATCA 1 2-3-5 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Ingeniería de Software Carrera: Ingeniería en Sistemas Computacionales Clave de la asignatura: SATCA 1 SCD-1011 2-3-5 2.- PRESENTACIÓN Caracterización

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

Formalización de Dominios de Negocio para Proyectos de Explotación de Información basada en Técnicas de Ingeniería del Conocimiento

Formalización de Dominios de Negocio para Proyectos de Explotación de Información basada en Técnicas de Ingeniería del Conocimiento Formalización de Dominios de Negocio para Proyectos de Explotación de Información basada en Técnicas de Ingeniería del Conocimiento Vegega, C., Pytel, P., Ramón, H., Rodríguez, D., Pollo-Cattaneo, F.,

Más detalles

Universidad Juárez Autónoma de Tabasco División Académica Multidisciplinaria de los Ríos Licenciatura en Informática Administrativa

Universidad Juárez Autónoma de Tabasco División Académica Multidisciplinaria de los Ríos Licenciatura en Informática Administrativa PROGRAMA DE ESTUDIO Aplicaciones multiplataforma Programa Educativo: Licenciatura en Informática Administrativa Área de Formación : Integral profesional Horas teóricas: 2 Horas prácticas: 2 Total de Horas:

Más detalles

HERRAMIENTAS Y ENTORNOS DE PROGRAMACIÓN

HERRAMIENTAS Y ENTORNOS DE PROGRAMACIÓN HERRAMIENTAS Y ENTORNOS DE PROGRAMACIÓN Tema 2. Tecnologías CASE Escuela Superior de Informática 1 Tema 2. Tecnologías CASE. Tecnologías CASE (~ 4 horas) Introducción. Conceptos, Objetivos, Herramientas

Más detalles

Análisis de la gestión de configuración de software aplicada al modelo de espiral

Análisis de la gestión de configuración de software aplicada al modelo de espiral Análisis de la gestión de configuración de software aplicada al modelo de espiral Abstract No hay nada permanente, excepto el cambio Heráclito (540 475 A.C.)- Grecia Fernandez, Sebastian Osso, Mariano

Más detalles

Nombre de la asignatura: Proceso Personal para el Desarrollo de - --------------------------------------------------Software

Nombre de la asignatura: Proceso Personal para el Desarrollo de - --------------------------------------------------Software 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Proceso Personal para el Desarrollo de - --------------------------------------------------Software Carrera: Clave de la asignatura: Ingeniería en Sistemas

Más detalles

Carrera: SCD-1008 SATCA 1 2-3-5

Carrera: SCD-1008 SATCA 1 2-3-5 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Fundamentos de programación Sistemas Computacionales Clave de la asignatura: SATCA 1 SCD-1008 2-3-5 2.- PRESENTACIÓN Caracterización de la asignatura.

Más detalles