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

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

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

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

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

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

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

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

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

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

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

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

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos

Repetir el proceso para cada abstracción identificada hasta que el diseño este expresado en términos sencillos I. INTRODUCCIÓN El reciente aumento de aplicaciones en donde se utiliza la computadora ha sido posible debido a un hardware de bajo costo, por lo cual la demanda de software ha crecido de forma exponencial.

Más detalles

Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web

Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web J.Corral-García, D.Cortés-Polo, C.Gómez-Martín, J.L.González-Sánchez

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

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

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

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

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

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

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

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

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

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

INGENIERÍA DEL SOFTWARE

INGENIERÍA DEL SOFTWARE INGENIERÍA DEL SOFTWARE Sesión No. 2 Nombre: Procesos de ingeniería del software INGENIERÍA DEL SOFTWARE 1 Contextualización La ingeniería de software actualmente es muy importante, pues con los avances

Más detalles

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

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

Más detalles

Capítulo I. Marco Teórico

Capítulo I. Marco Teórico 1 Capítulo I. Marco Teórico 1. Justificación Hoy en día existe una gran diversidad de aplicaciones que corren sobre la World Wide Web (WWW o Web), y cada una orientada a un fin en particular, el cuál depende

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

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

SYSTEMIC SOLUTIONS BPM. soluciones integrales. informes@systemicsolutions.biz

SYSTEMIC SOLUTIONS BPM. soluciones integrales. informes@systemicsolutions.biz SYSTEMIC SOLUTIONS soluciones integrales Hacer realidad BPM en su Organización informes@systemicsolutionsbiz MODELO DE NEGOCIO SYSTEMIC SOLUTIONS es una empresa especializada en formación, consultoría

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

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

Procesos de Negocios

Procesos de Negocios Procesos de Negocios Procesos de negocios Como dijimos en el Tema 1: los sistemas de información y las organizaciones se influyen entre sí: Los SI deben proveer la información que la organización necesita.

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

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

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

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

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

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

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

Más detalles

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

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

Más detalles

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

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

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

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

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

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

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

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

3. OBJETIVOS. 3.1. Objetivos. Objetivos generales del título. Objetivos específicos del título

3. OBJETIVOS. 3.1. Objetivos. Objetivos generales del título. Objetivos específicos del título 3. OBJETIVOS 3.1. Objetivos Objetivos generales del título De acuerdo con lo establecido en el Libro Blanco y el acuerdo del plenario de la Conferencia de Directores y Decanos de Informática (Zaragoza,

Más detalles

CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE

CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE CONCEPTOS DE CALIDAD Y CALIDAD DEL SOFTWARE INTRODUCCIÓN El avance informático actual es muy alto comparado con lo se tenía en los años 90, al hablar de desarrollo de software se hace más notable, en el

Más detalles

TEMA 1 Sistemas de información

TEMA 1 Sistemas de información TEMA 1 Sistemas de información María N. Moreno García Departamento de Informática y Automática Universidad de Salamanca Contenidos 1. Conceptos básicos 2. Elementos de un sistema de información 3. Estructura

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

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

Carrera: SCM - 0406 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos.

Carrera: SCM - 0406 3-2-8. Participantes. Representantes de la academia de sistemas y computación de los Institutos Tecnológicos. 1.- DATOS DE LA ASIGNATURA Nombre de la asignatura: Carrera: Clave de la asignatura: Horas teoría-horas práctica-créditos Desarrollo de proyectos de software Ingeniería en Sistemas Computacionales SCM

Más detalles

Collaborative Lifecycle Management

Collaborative Lifecycle Management Collaborative Lifecycle Management IBM Rational Software Portafolio.. Documentación Técnica... COLLABORATIVE LIFECYCLE MANAGEMENT La solución de IBM Rational para la Gestión del Ciclo de Vida Colaborativo

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

Arquitectura de desarrollo Fomento.Net

Arquitectura de desarrollo Fomento.Net Casos de éxito everis Arquitectura de desarrollo Fomento.Net Resumen País: España. Sector: Administración. Perfil del Cliente Subdirección General de Tecnologías y Sistemas de la Información (SGTSI) del

Más detalles

Análisis de Requerimientos

Análisis de Requerimientos Análisis de Requerimientos Ing. Luis Zuloaga Rotta Situación de la Industria de Software Mas del 30% de todos los proyectos de software son cancelados antes de su finalización. Mas del 70% de los proyectos

Más detalles

Asignaturas antecedentes y subsecuentes

Asignaturas antecedentes y subsecuentes PROGRAMA DE ESTUDIOS Ingeniería de Software Área a la que pertenece: Área Sustantiva Profesional Horas teóricas: 3 Horas prácticas: 1 Créditos: 7 Clave: F0161 Asignaturas antecedentes y subsecuentes PRESENTACIÓN

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

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

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

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

Ingeniería de Software

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

Más detalles

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

MODELADO DE OBJETOS DE DATOS

MODELADO DE OBJETOS DE DATOS Manual Página Web MODELADO DE OBJETOS DE DATOS MANUALES ESPECIALES Documento: Manual Páginas Web (SemanticWebBuilder). Fecha de Elaboración: Marzo de 2009. INFOTEC CONACYT FIDEICOMISO. Página i Glosario

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

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Jorge Bozo jbozo@inf.ucv.cl Escuela de Ingeniería Informática Universidad Católica de Valparaíso Valparaíso, Chile

Más detalles

BOLETÍN DE NOVEDADES Barcelona, junio de 2008

BOLETÍN DE NOVEDADES Barcelona, junio de 2008 BOLETÍN DE NOVEDADES Barcelona, junio de 2008 Introducción El objeto de este documento es presentar y describir brevemente las principales actuaciones en los últimos meses de Carver en algunos de sus clientes,

Más detalles

INGENIERÍA EN SISTEMAS COMPUTACIONALES (ISIC-2010-224)

INGENIERÍA EN SISTEMAS COMPUTACIONALES (ISIC-2010-224) INGENIERÍA EN SISTEMAS COMPUTACIONALES (ISIC-2010-224) ÁREAS DE CONOCIMIENTO DESCRITAS Lenguajes de Programación. Bases de Datos. Redes de Computadoras. Arquitectura de Computadoras. Programación Web.

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

: COMPUTACIÓN E INFORMATICA : Ingeniería de Software Ingeniería de Redes y Comunicaciones : Análisis y Diseño de Sistemas : T-INF107

: COMPUTACIÓN E INFORMATICA : Ingeniería de Software Ingeniería de Redes y Comunicaciones : Análisis y Diseño de Sistemas : T-INF107 I. DATOS INFORMATIVOS Carrera Especialidad Curso Código Ciclo : Tercero Requisitos Duración Horas Semana : 06 horas Versión : v.0110 II. SUMILLA: : COMPUTACIÓN E INFORMATICA : Ingeniería de Software Ingeniería

Más detalles

ITBA - UPM MAGISTER EN INGENIERIA DEL SOFTWARE ANTEPROYECTO DE TESIS

ITBA - UPM MAGISTER EN INGENIERIA DEL SOFTWARE ANTEPROYECTO DE TESIS ITBA - UPM MAGISTER EN INGENIERIA DEL SOFTWARE ANTEPROYECTO DE TESIS TÍTULO: TEMA: Sistema generador del mapa de actividades de un proyecto de desarrollo de software. Sistema basado en conocimientos para

Más detalles

UML 2 Iniciación, ejemplos y ejercicios corregidos

UML 2 Iniciación, ejemplos y ejercicios corregidos Ediciones ENI UML 2 Iniciación, ejemplos y ejercicios corregidos (3ª edición) Colección Recursos Informáticos Contenido Contenido 1 Capítulo 1 Introducción 1. Motivaciones de la obra.....................................

Más detalles

A partir de este capítulo se introducen términos, probablemente nuevos para el

A partir de este capítulo se introducen términos, probablemente nuevos para el CAPITULO 3. PSP 0 Y PSP 0.1 A partir de este capítulo se introducen términos, probablemente nuevos para el lector que tienen que ver en su totalidad con PSP. También se dan a conocer los formatos, "scripts

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

El desarrollo de aplicaciones

El desarrollo de aplicaciones e d i t o r i a l Entendiendo el desarrollo de los sistemas SOA María Consuelo Franky R. El desarrollo de aplicaciones orientadas y basadas en servicios, como estilo de arquitectura, emergió sobre la arena

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

CAPÍTULO II. Gráficos Dinámicos.

CAPÍTULO II. Gráficos Dinámicos. 2.1 Definición. Los gráficos dinámicos son representaciones a escala del proceso, en donde se muestra la información de las variables del proceso a través de datos numéricos y de animación gráfica. Éstos

Más detalles

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software IX Contenidos Prólogo... XIX Prefacio... XXI Guía de lectura...xxiii Parte I - Introducción Capítulo 1 - Evolución 1.1 Introducción... 2 1.2 Los hitos en la evolución histórica del desarrollo de software...

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

Implantación y Aceptación del Sistema

Implantación y Aceptación del Sistema y Aceptación del Sistema 1 y Aceptación del Sistema ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD IAS 1: ESTABLECIMIENTO DEL PLAN DE IMPLANTACIÓN...5 Tarea IAS 1.1: De finición del Plan de... 5 Tarea IAS

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

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

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

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

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

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

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

Ingeniería de Software

Ingeniería de Software Ingeniería de Software 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. Definiciones

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

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008)

Unidades temáticas de Ingeniería del Software. Fases del proceso de desarrollo 4ª edición (2008) Unidades temáticas de Ingeniería del Software Fases del proceso de desarrollo 4ª edición (2008) Facultad de Informática organización del desarrollo El ciclo de vida del software abarca el proceso de desarrollo,

Más detalles

Aplicaciones Distribuidas con Visual Studio 2005

Aplicaciones Distribuidas con Visual Studio 2005 Aplicaciones Distribuidas con Visual Studio 2005 24.10.2006 Servicios Profesionales Danysoft Ahora los arquitectos en.net disponen de una versión de Visual Studio especialmente creada para atender sus

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

Empresa Financiera Herramientas de SW Servicios

Empresa Financiera Herramientas de SW Servicios Empresa Financiera Herramientas de SW Servicios Resulta importante mencionar que ésta es una empresa cuya actividad principal está enfocada a satisfacer las necesidades financieras de los clientes, a través

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

Taller de Sistemas de Información 1. Clase 2 Sistemas de información Arquitectura

Taller de Sistemas de Información 1. Clase 2 Sistemas de información Arquitectura Taller de Sistemas de Información 1 Clase 2 Sistemas de información Arquitectura Sistemas Empresariales Es una descripción de las metas de una organización, como estas metas son realizadas a través de

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