Metodología para el diseño y desarrollo de interfaces de usuario

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "Metodología para el diseño y desarrollo de interfaces de usuario"

Transcripción

1 Metodología para el diseño y desarrollo de interfaces de usuario Versión <1.1> Historia de Revisión Fecha Versión Descripción Responsable 20/06/2005 <0.1> Creación. Alejandro Báez Cristian Castañeda Diego Castañeda 3/07/2005 <1.0> Se especifican con mayor Alejandro Báez detalle las etapas de la Cristian Castañeda metodología y se analizan nuevos aspectos de las Diego Castañeda interfaces gráficas 25/07/2005 <1.1> Se añadió el diagrama para Alejandro Báez modelamiento de procesos. Cristian Castañeda Diego Castañeda INVESTIGADORES: ALEJANDRO BAEZ CRISTIAN CASTAÑEDA DIEGO CASTAÑEDA DIRECTOR: JAVIER SÁNCHEZ

2 TABLA DE CONTENIDO TABLA DE CONTENIDO Introducción Análisis, diseño, implementación y pruebas de una aplicación en J2EE Modelo de negocio Análisis de requerimientos Documento de requerimientos Definición de los usuarios del Sistema Requerimientos Funcionales Requerimientos No Funcionales Requerimientos de interfaz Documento de casos de uso Definición de actores Definición de casos de uso Diagrama de casos de uso Diseño del sistema Diseño de la lógica del negocio Modelo entidad relación Modelo de clases persistentes: Modelo de acceso a los datos (Patrón DAO) Definición de servicios Diseño de las interfaces de usuario Implementación Pruebas Relación con RUP Qué es RUP? Fase de Inicio Fase de Elaboración Fase de Construcción Fase de Transición Artefactos Artefacto RUP en nuestra metodología Interfaz gráfica J2EE Elementos funcionales de una interfaz grafica Validaciones Información a presentar y recolectar Relación entre datos Flujo de Páginas Elementos de diseño de una interfaz grafica Diseño estructural Encabezado Menú... 26

3 Zona de Contenido Hojas de Estilo Componentes Zona de Mensajes Diagrama de navegabilidad Otros problemas Seguridad Reportes Performance Integración con otro Software... 29

4 1. Introducción Framework unificado para desarrollo de interfaces J2EE Uno de los principales problemas en el desarrollo de aplicaciones J2EE es el poco conocimiento que se tiene de cómo unir la lógica del negocio con la forma en que se presentara esta a los usuarios finales del software. Es por eso de vital importancia para el desarrollo de este proyecto, la definición de una metodología que nos ayude a decir como se debe realizar este proceso, para reducir la complejidad inherente de este tipo de desarrollos. El objetivo de este documento es presentar una metodología para el análisis, diseño, implementación y pruebas en desarrollos de software en J2EE, además de esto definir como diseñar las interfaces graficas de usuario en este tipo de aplicaciones y describir algunos problemas que se deben tener en cuenta en el desarrollo de interfaces pero que van mas allá del alcance de este proyecto.

5 2. Análisis, diseño, implementación y pruebas de una aplicación en J2EE Desarrollando el caso de prueba de nuestro proyecto 1, se han podido identificar una serie de etapas que se deben realizar para la construcción de aplicaciones J2EE. Estas etapas son un modelo general que hemos desarrollado a partir de nuestra experiencia, pero el orden y cumplimiento de las fases no es obligatorio, depende de las características especificas de la aplicación. A continuación se muestran las etapas que consideramos se deben realizar en la construcción de una aplicación J2EE: Modelo de negocio Análisis de requerimientos Diseño del sistema Diseño de la lógica del negocio Diseño de las interfaces de usuario Implementación Pruebas 2.1 Modelo de negocio En esta etapa, se deben definir cuales son los procesos y procedimientos que se tienen en el escenario para el cual se va a desarrollar la aplicación. Esto permite identificar los casos concretos que debe automatizar el sistema, la relación que debe existir entre la ingeniería de software y el negocio, con el fin de aclarar el enfoque que quiere tener el cliente con el software. Un procedimiento se puede entender como un método estructurado para ejecutar una tarea. Un proceso es un conjunto de procedimientos que se deben realizar para alcanzar un objetivo, el cual representa una función que debe cumplir para el escenario que se estudiando. Típicamente de un procedimiento se debe conocer: ID: identifica de manera única un procedimiento. Nombre: identificador único del procedimiento. Objetivo: Indica la finalidad que se busca alcanzar con el desarrollo del procedimiento. Predecesor: Indica un procedimiento que se debe realizar antes de realizar el procedimiento. Personas implicadas: Indica las personas encargadas en desarrollar el procedimiento. 1 Remitirse a los documentos de requerimientos, casos de uso y arquitectura de la videotienda en la pagina

6 Impacto: Indica los efectos producidos por la ejecución del procedimiento. Tiempo de realización: Indica el tiempo promedio de duración del procedimiento. Descripción: Indica de manera detallada todos los pasos que se deben cumplir para la realización del procedimiento. Resultados esperados: Indica los resultados que se deben obtener luego de la realización del procedimiento. Para un proceso se deben conocer: Nombre: identificador único del proceso Objetivo: Indica la finalidad que se busca alcanzar con el desarrollo del proceso. Alcance: Define de manera específica las áreas, departamentos, procesos, etc. que van a ser afectadas por el proceso y sus resultados. Importancia: Indica el nivel de prioridad del proceso respecto a otros. Tiempo de realización: Indica el tiempo promedio de duración del proceso. Procesos con los que se relaciona: Indica los procesos que intervienen o se ven afectados con el desarrollo del proceso. Resultados esperados: Indica los resultados que se deben obtener luego de la realización del proceso. Procedimientos implicados: Indica el conjunto de procedimientos que incluye el desarrollo de este proceso. Para la recolección de la información de procesos y procedimientos hemos definido el siguiente formato: Numero del proceso: Nombre del Proceso: Objetivo: Alcance: Importancia: Tiempo: Procesos relacionados: Resultados esperados: Procedimientos ID Nombre Objetivo Predecesor Personas Implicadas Impacto Tiempo Descripción Resultados Luego de llenar este formato para todos los procesos que se quieren analizar, se podrá determinar que procesos van a ser automatizados por el sistema. Para estos procesos se deberán realizar las etapas posteriores de la metodología. Con el fin de tener más criterios para determinar estos procesos que va a ser

7 automatizados, es útil realizar un gráfico propuesto por JBOSS 2 que represente el flujo de un proceso. Para construir este gráfico es importante tener en cuenta los siguientes conceptos: Nodo de Inicio: Representa el comienzo del flujo de un proceso y se identifica de la siguiente forma: Nodo de Fin: Es el nodo que indica el final de un proceso y se representa de la siguiente manera: End Nodo de Decisión: Es el nodo que indica una o varias opciones para continuar el flujo del proceso, basado en un criterio de decisión; se representa de la siguiente manera. Criterio 1 Nodo de Procedimiento: Este nodo representa una o varias actividades a ser realizadas, en este punto del flujo del proceso. Tarea 1 Nodo de División de tareas concurrentes: Este nodo divide el proceso en varios flujos, que se llevaran a cabo en paralelo; al final de los mismos se deben unificar usando este mismo nodo. Gráficamente se representa de la siguiente manera: Transiciones: Acción que implica al flujo un cambio de estado, se representa con una flecha y la acción a tomar. Facturación Un ejemplo que presenta JBOSS para la explicación es el manejo de una subasta en un sitio de Internet: 2 Process Modelling, JBOSS,

8 2.2 Análisis de requerimientos El análisis de requerimientos es la etapa mas importante del desarrollo de software, para poder hablar de ella primero tenemos que definirla; Para esto utilizaremos la siguiente definición que hace Microsoft: El análisis de requerimientos es la primera etapa de un proyecto software, en ella se tratan de definir las condiciones o capacidades necesarias para uno o varios usuarios con el fin de solucionar un problema o conseguir un objetivo. 3 Como se indica en esta definición, el objetivo de el análisis de requerimientos es determinar las condiciones o capacidades que debe cumplir el sistema que se quiere diseñar para satisfacer las necesidades de un grupo de usuarios. Para lograr esto utilizaremos la definición de requerimientos. Un requerimiento se puede entender como una descripción informal de las necesidades y deseos que tiene el usuario final respecto a un producto de software. Para lograr el levantamiento de estos requerimientos consideramos que se deben construir los siguientes artefactos: documento de requerimientos y el documento de casos de uso. 3 Para Mayor Información diríjase a:

9 2.2.1 Documento de requerimientos En el documento de requerimientos se especifican las características y funcionalidades que debería cumplir el sistema, para satisfacer los procesos y procedimientos que se han determinado para ser automatizados. Este documento debe contener al menos la siguiente información 4 : Definición de los usuarios del sistema Requerimientos Funcionales Requerimientos no funcionales Requerimientos de Interfaz Glosario Este análisis servirá como base para el diseño de la aplicación Definición de los usuarios del Sistema En esta sección del documento de requerimientos se busca identificar las características de los usuarios que interactuaran con el sistema. Para esto se utilizara la definición de roles. Un rol es un conjunto de funciones que debe cumplir el papel de una persona que interactúa con el sistema. Para la definición de un rol, se deben especificar los siguientes elementos: Nombre: identificador único de un grupo de usuarios que interactúan con el sistema. Funciones: Conjunto de tareas que cumplen este tipo de usuarios. Privilegios: Conjunto de derechos que deben tener este tipo de usuarios dentro del sistema Requerimientos Funcionales Los requerimientos funcionales son todas las funcionalidades que debe satisfacer el sistema para cumplir con las necesidades de los usuarios, a partir del análisis del negocio que se halla hecho. Para la definición de los requerimientos funcionales se deben especificar los siguientes elementos. Id: Identifica de manera única un requerimiento. Nombre: identificador de un requerimiento. Descripción: Indica una funcionalidad que debe cumplir el sistema. Prioridad: indica la importancia de un requerimiento(baja, Media, Alta). 4 Para mas información remitirse al estándar IEEE (SRS)

10 Requerimientos No Funcionales Los requerimientos no funcionales son todos aquellas características que debe cumplir el sistema para responder de manera adecuada a todos los requerimientos Funcionales y a las características de funcionamiento que requiera el usuario. Para la definición de los requerimientos no funcionales se deben identificar lo siguientes elementos: Id: Identifica de manera única un requerimiento. Nombre: identificador de un requerimiento. Descripción: Indica una característica del sistema que ayudara a satisfacer los requerimientos funcionales Prioridad: indica la importancia de un requerimiento(baja, Media, Alta) Requerimientos de interfaz Los requerimientos de interfaz son todos aquellos elementos que debe proveer el sistema para permitir la interacción entre el usuario y las funcionalidades que este tiene, con el fin de que en el proceso de diseño se tenga claridad de las interfaces que se deben crear y la relación que debe existir entre ellas. Para la definición de los requerimientos de interfaz se deben identificar lo siguientes elementos: Id: Identifica de manera única una interfaz gráfica Descripción: Indica los elementos que debe tener la interfaz. Requerimientos asociados: Indican las funcionalidades asociadas a la interfaz gráfica. En este nivel, no se va definir de manera detallada la interfaz, solo se pretende tener una primera aproximación a los elementos que deben ser tenidos en cuenta en el desarrollo de estas Documento de casos de uso Luego de desarrollar el documento de requerimientos, se debe construir el documento de casos de uso. Este documento consiste básicamente en la definición de un conjunto de casos de uso. Un caso de uso es: narración que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso 5. 5 UML y Patrones, Larman, 1999.

11 La definición de estos casos de uso es útil para conocer los procesos del dominio y el ambiente externo, dentro de los cuales se ejecutan los requerimientos anteriormente descritos. El documento de casos de uso deberá contener al menos la siguiente información: Definición de actores Definición de casos de uso Diagrama de casos de uso Definición de actores En esta sección del documento de casos de uso, se especificaran el tipo de personas que de alguna manera interactúan en alguno de los procesos del sistema, estos actores estimulan al sistema con eventos de entrada o la recepción de algún resultado que este produzca. Para la definición de los actores se deben identificar los siguientes elementos: Nombre: Identifica de manera única un tipo de actor. Papel: Indica el tipo de estimulación que ejerce el actor sobre el sistema Definición de casos de uso En esta sección del documento de casos de uso, se definen de manera formal todos los casos de uso en los cuales se ejecutan cada uno de los requerimientos funcionales que se especificaron en el documento de requerimientos (véase 2.2.1) Para la definición de cada caso de uso se deben tener en cuenta al menos los siguiente elementos: Nombre: Identifica de manera única un caso de uso. Actores involucrados: Indica los actores que de alguna manera participan en el desarrollo del caso de uso. Propósito: Indica la finalidad que se busca con el caso de uso. Resumen: Breve descripción de los eventos que se realizan en el caso de uso. Tipo: Indica si la implementación del caso de uso es opcional u obligatoria. Importancia: Indica el nivel de prioridad del caso de uso(baja, Media, Alta). Curso normal y alterno de los eventos: Indica la secuencia de eventos que suceden en la realización del caso de uso, especificando un curso normal y alterno, dependiendo si se presenta o no algún evento inesperado que afecte el desarrollo del caso de uso. Requerimientos que satisface: Hace una referencia a los identificadores de los requerimientos que satisface el caso uso.

12 Diagrama de casos de uso En esta sección del documento de casos de uso, se presenta el diagrama de casos de uso. Un diagrama de casos de uso Explica gráficamente un conjunto de casos de uso de un sistema, los actores y la relación entre estos y los casos de uso. 6 Para mayor información para la realización de estos diagramas a la especificación de UML 7. 6 UML y Patrones, Larman, UML (Unified Model Language),

13 2.3 Diseño del sistema En el diseño del sistema se pretende definir la arquitectura que utilizara la aplicación, con el desarrollo del caso de prueba, hemos creído que es conveniente utilizar una arquitectura multicapas, donde se tendrán al menos las siguientes capas: Interfaz (Web): Se encarga de la presentación de la aplicación al usuario. Servicios (negocio y Web): Se encarga de definir un conjunto de funcionalidades para que la capa de interfaz se las presente al usuario. Manejador de persistencia: Se encarga de establecer un puente para que la capa de servicios acceda a la información que reside en la base de datos. Base de datos: Se encarga de mantener de manera persistente la información del sistema. Este tipo de arquitectura se puede considerar genérico para el desarrollo de aplicaciones J2EE; en nuestro caso hemos decidido utilizar los siguientes frameworks: Interfaz: Java Server Faces (JSF), Tapestry Servicios: JBoss y Tomcat Manejador de persistencia: Hibernate Base de datos: Oracle Gráficamente la arquitectura es: Tomcat Inter net JBOSS HIBERNATE ORACLE La herramienta que se desarrollara, servirá para la creación de aplicaciones con la arquitectura anteriormente descrita.

14 2.4 Diseño de la lógica del negocio Framework unificado para desarrollo de interfaces J2EE En esta etapa se deberá diseñar un modelo apropiado para satisfacer los requerimientos y casos de uso que se especificaron en etapas anteriores utilizando la arquitectura que se ha definido. Realizando nuestro caso de prueba, hemos podido identificar los siguientes items que al menos se deben realizar 8 : Modelo entidad relación Modelo de clases persistentes Modelo de acceso a los datos (Patrón DAO 9 ) Definición de servicios Modelo entidad relación El modelo entidad relación es uno de los modelos conceptuales mas utilizados para el diseño de bases de datos, el propósito de este modelo es simplificar el diseño de bases de datos a partir de descripciones textuales de los requerimientos 10. Para la construcción de este modelo se utilizan fundamentalmente los siguientes elementos: Entidad: Abstracción que representa un objeto de la vida real. Atributo: Característica que representa un aspecto común de la entidad Relación: Representa una interacción entre entidades. Luego del proceso de análisis del sistema, se deben establecer un conjunto de entidades, con sus atributos, que permitan representar todos los objetos que están involucrados en el problema a solucionar. Con este conjunto de entidades y con el documento de casos de uso, se deberán establecer las relaciones entre estas. El objetivo del modelo de entidad relación es representar gráficamente estas entidades y las relaciones que existen entre ellas, así como definir la estructura que debe existir en la base de datos El orden de realización de estos productos no es estricto. Se puede utilizar otros diagramas útiles para el diseño, para mayor información remítase a la especificación de UML. 9 Data Access Object, patrón que sirve para encapsular y administrar el acceso a los datos. 10 Modelo entidad relación, 11 Para mayor información: SILBERSCHATZ, A., et al. Fundamentos de Bases de Datos. Cuarta Edición. McGraw Hill. 2002

15 2.4.2 Modelo de clases persistentes: Este modelo sirve para hacer un mapeo entre la información que se encuentra almacenada en la base de datos y los objetos que se tendrán dentro de la aplicación. Es importante aclarar que en este modelo no representara directamente todas las funcionalidades que debe tener el sistema, sino que servirá como soporte al patrón DAO. En términos de nuestro contexto, cada una de estas clases es un POJO Modelo de acceso a los datos (Patrón DAO) Este modelo sirve para separar el acceso a los datos con la lógica del negocio, esto permite que se defina un nivel mas que permita la protección a la integridad y consistencia de los datos. Consiste en definir un conjunto de clases que tendrán un grupo de métodos que se encargan de todas las operaciones sobre los POJO s que se definieron en el modelo de clases persistentes. Típicamente se tendrán que ofrecer operaciones CRUD 13 y búsquedas Definición de servicios En esta fase se deberán definir un conjunto de servicios que se deben proveer para satisfacer a los requerimientos y funcionalidades que fueron definidos anteriormente para la aplicación, es decir, se encargaran de implementar la lógica del negocio. Estos servicios serán utilizados por el servidor Web para establecer un puente entre la lógica del negocio y la presentación. Para nuestro contexto, consideramos que para un servicio se deben definir: Precondición: Es una condición que ha de satisfacerse justo antes del comienzo de la ejecución de un servicio. Poscondición: Indica cual debe ser el estado de los datos después de haber realizado el servicio. Definición: Da una descripción de lo que debe hacer el servicio Prototipo del método: Muestra el prototipo de cómo se implementara el servicio. Con la definición de los servicios, se puede tener claro como van a ser implementados los requerimientos funcionales del sistema; esta información será vital para el proceso de integración de la aplicación. 12 Persistent Old Java Object, objeto al cual solo se le definen los atributos, los set y get para accesarlos. 13 Create, Read, Update, Delete. Operaciones que básicamente se hacen sobre los datos

16 2.5 Diseño de las interfaces de usuario Una de las etapas a las que menos tiempo se les invierte es al diseño de las interfaces graficas, por tal razón en el momento de implementarlas no se tiene claro que es lo que se debe hacer, generando errores e inconsistencias lo que hace que su desarrollo sea lento y complejo. Por eso es una buena práctica, establecer en los cronogramas un tiempo para el diseño de estas, para evitar que estos problemas se presenten. El problema del diseño de las interfaces gráficas se analizara al detalle en la sección 4 de este documento. 2.6 Implementación En esta etapa se debe llevar a la realidad todo lo que se ha descrito en los modelos de las fases anteriores. Para tener un buen proceso de implementación se recomienda tener en cuanta los siguientes aspectos: Manejo de versiones Definición de iteraciones Documentación Estos aspectos se van tratar con mas detalle en la sección 3, donde se establece la relación entre nuestra metodología y RUP. 2.7 Pruebas La ultima etapa de nuestra metodología, busca asegurar que las funcionalidades implementadas en el sistema funcionen de acuerdo a las especificaciones, para esto se deben definir un conjunto de pruebas que nos ayuden a verificar esto. La definición de las pruebas y la administración podrán ser manejadas con RUP, ver la sección Relación con RUP En la actualidad una de las metodologías mas utilizadas para desarrollos de software es RUP (Rational Unified Process), por eso es de vital importancia para la especificación de nuestra metodología, establecer como podemos entender nuestras etapas según el ciclo de vida que se define en RUP. Para poder establecer esta relación, primero debemos definir que es RUP.

17 3.1 Qué es RUP? Framework unificado para desarrollo de interfaces J2EE RUP es un proceso de Ingeniería de Software en el cual se especifican una serie de tareas que se deben realizar con el fin de asegurar un producto de Software de alta calidad a sus usuarios finales. Dentro de RUP se pueden identificar cuatro etapas que son: Inicio Elaboración Construcción Transición En cada una de estas etapas se propone la ejecución de una serie de disciplinas, que se deben ejecutar de forma iterativa para cada una de las fases. Estas disciplinas son: Modelamiento del negocio: Busca identificar el negocio, para el cual se realizara el proyecto. Levantamiento de requerimientos: Identifica los procesos que deben ser automatizados, la manera como se deben proveer estos y los objetivos del proyecto. Análisis y Diseño: Se busca determinar una solución para alcanzar los objetivos del proyecto. Implementación: Disciplina donde se busca llevar a la realidad la solución que se definió en el análisis y diseño. Pruebas: Busca comprobar la correcta implementación de la solución dada. Cada una de estas disciplinas se debe realizar en mayor o menor medida dependiendo de la fase del proyecto en que se encuentre; A continuación especificaremos cuales son los objetivos de estas fases Fase de Inicio La fase de Inicio tiene los siguientes objetivos: Establecer el objetivo y el alcance del proyecto de Software. Determinar requerimientos y casos de uso. Dar una primera aproximación de la arquitectura en la cual se desarrollará el proyecto de Software. Estimar los costos y el cronograma del proyecto de Software Estimar los riesgos potenciales del proyecto de Software. Preparar un ambiente de soporte para el proyecto.

18 3.1.2 Fase de Elaboración La fase de Elaboración tiene los siguientes objetivos: Asegurar que la arquitectura escogida cumpla los requerimientos y planes previamente establecidos. Definir los riesgos que la arquitectura escogida pueda traer al proyecto. Establecer una línea de base de la arquitectura para mitigar los riesgos en los distintos escenarios y que soporte los requerimientos especificadas a un costo y tiempo razonable. Construir un prototipo que permita visualizar al usuario final una posible solución del problema con el fin de mitigar riesgos en el futuro y además levantar nuevos requerimientos del sistema Fase de Construcción La fase de construcción tiene los siguientes objetivos: Minimizar los costos y optimizar los recursos del proyecto. Alcanzar los niveles de calidad adecuados. Utilizar un control de versiones que sean practicas y rápidas. Completar el análisis, diseño y desarrollo y probar todos los requerimientos funcionales. Iterativamente e incrementalmente desarrollar la totalidad del producto. Permitir la modularidad del producto con el fin de tener equipos de software que desarrolle en paralelo Fase de Transición La fase de transición tiene los siguientes objetivos: Prueba para validar el nuevo sistema ante las expectativas del usuario final. Capacitación a usuario y administradores del sistema Valorar si la línea base del desarrollo cumple con la visión del proyecto y los criterios de aceptación de este. Establecer un plan de soporte para el proyecto Artefactos Debido a que el proceso de RUP es iterativo, no se puede definir claramente en que etapa se deben desarrollar los diferentes artefactos que propone RUP, en términos generales consideramos que los siguientes artefactos son los mas importantes que define este proceso:

19 Artefacto Descripción Disciplina Modelo de Casos de Uso del negocio Relaciona los casos de uso del negocio con sus actores y relaciones. Modelo del Negocio Modelo de Objetos del Negocio Especificación de requerimientos Casos de Uso Relaciona en un modelo la organización las entidades y trabajadores del negocio. Identifica las necesidades que debe satisfacer el sistema. Identifica un escenario, los eventos y actores para la realización de un proceso del negocio. Modelo del Negocio Levantamiento de requerimientos Levantamiento de requerimientos Modelo de Casos de Uso Relaciona gráficamente los casos de uso. Levantamiento de requerimientos Especificación de Define la arquitectura sobre la que se Análisis y Diseño arquitectura desarrollara el software Modelo de datos Define el modelo sobre el cual se Análisis y Diseño creara la base de datos. Diseño de clases Define la forma en que se Análisis y Diseño implementara la solución. Diseño de paquetes Identifica los paquetes con los que Análisis y Diseño se implementaran la solución. Pantallas Define las interfaces de usuario. Análisis y Diseño Mapa de Navegación Indica la navegación entre las Análisis y Diseño pantallas de usuario. Plan de Pruebas Define las pruebas que se le Implementación realizara al software Código Fuente Implementación de la solución. Implementación Resultado de pruebas Documenta los resultados de las pruebas. Pruebas Esta sección es una breve introducción al proceso de RUP, fue extraída de el documento About the RUP Configuration for Java Developers RUP en nuestra metodología Como pudimos darnos cuenta en la anterior sección RUP ofrece una metodología de desarrollo, donde se pueden identificar una serie de etapas, que aunque independientes se relacionan de manera muy fuerte por su proceso iterativo, esta relación es muy importante para que se pueda asegurar la calidad en el desarrollo del software. En nuestra metodología hemos podido identificar una serie de 14 RUP Configuration for Java Developers, Version , Rational Software Corporation

20 disciplinas, que aunque no son exactamente iguales a las que propone RUP, buscan cumplir con ese criterio de calidad. A continuación, asociaremos nuestras disciplinas con las cuatro etapas que propone RUP: En el grafico nos podemos dar cuenta, que nuestras disciplinas están pensadas para realizarse mediante un proceso iterativo. Esto quiere decir que luego de realizarse por completo cada una de estas disciplinas se va a realizar nuevamente con base a la versión anterior, mejorándola hasta que cumpla con las necesidades planteadas. Por otra parte nuestros artefactos aunque no son iguales a los que RUP propone, son capaces de alcanzar los objetivos que la metodología da para cada caso. A continuación, vamos a relacionar nuestros artefactos con las diferentes disciplinas que propone RUP: Artefactos Modelo del Negocio Documento de Requerimientos Documento de Casos de Uso Modelo entidad relación Modelo de clases persistentes Modelo de acceso a los Datos Disciplinas RUP Modelo del Negocio Levantamiento de requerimientos Levantamiento de requerimientos Análisis y Diseño Análisis y Diseño Análisis y Diseño

21 Documento de Interfaces de usuario Implementación(Código Fuente) Pruebas Análisis y Diseño Implementación Pruebas De esta manera podemos ver como asociar la metodología propuesta con el proceso que realiza RUP, logrando seguir este pero con los pasos que en la metodología se proponen.

22 4. Interfaz gráfica J2EE En nuestra metodología encontramos la definición detallada de las interfaces gráficas, una nueva etapa en los desarrollos comunes de software. En esta sección se encuentran los pasos a seguir en el diseño y construcción de las mismas. Las pantallas deben permitir una forma de interacción entre el usuario y todas las funcionalidades que ofrece el sistema, cada una de ellas debe al menos presentar una funcionalidad para que su creación este justificada. Los elementos que se deben definir para cada pantalla son: Información a presentar o recolectar Validaciones Relación entre datos Flujo de paginas Los elementos comunes entre pantallas que se podrían definir son: Encabezado (Opcional) Menú (Opcional) Zona de Contenido Hojas de estilo (CSS) 15 Zona de mensajes (error, éxito) Una practica recomendable para verificar la completitud entre las paginas definidas y las funcionalidades del sistema es llenar una matriz como la que se muestra a continuación: Pagina 1 Pagina 2... Pagina m Funcionalidad 1 X Funcionalidad 2 X... X Funcionalidad n X El marcar la intersección entre una pagina y una funcionalidad, indica que la pagina implementa esa funcionalidad. 15 Las hojas de estilo en cascada permiten estandarizar la forma de presentación de los componentes en una pagina. Para mas información

23 En esta sección se describe en detalle componentes y características de las interfaces gráficas en desarrollos J2EE. Para llevar esto acabo dividimos los elementos de una interfaz gráfica en dos: los que hacen referencia a su funcionalidad y los que corresponden al diseño de la interfaz. 4.1 Elementos funcionales de una interfaz grafica Los elementos funcionales de una interfaz gráfica son los que definen el comportamiento de la misma, es decir aquellos cuyo objetivo es asegurar el funcionamiento adecuado y coherente de las pantallas del sistema, teniendo en cuenta los requerimientos que fueron planteados y que se necesita sean satisfechos. Para un correcto desempeño por parte de los mismos es necesario que trabajen conjuntamente, debido a que todos formarán el sistema y todos hacen que sea mas claro el funcionamiento del mismo. Entre los elementos a tener en cuenta encontramos: Validaciones Validación: Una validación se lleva a cabo cuando se compara un dato con un valor esperado, buscando coherencia e integridad. Las validaciones que se van tener en cuenta son: Tipo: Se evalúa el dato respecto al tipo que se especifico que debía ser. Los tipo que se tendrán en cuenta son: o Números (Enteros y decimales). o Cadena de Caracteres o Fechas. Longitud: Dependiendo de la longitud mínima o máxima que se requiera se evaluará si el dato cumple con esta característica. Obligatoriedad: Se valida si en algunos casos el usuario tiene que llenar un campo para realizar una operación. Caracteres Especiales: Dependiendo si el usuario necesita que algún tipo de dato tenga o no caracteres especiales se debe verificar si cumple con el requisito. Valores máximos(mínimos): En algunas aplicaciones los datos deben estar entre unos limites establecido según los requerimientos del sistema. Esto también debe ser evaluado

24 Las validaciones que se generen pueden ser agrupadas en código reutilizable(clase), que funcione para todas las pantallas que requieran las mismas Información a presentar y recolectar La información a presentar dependerá del rol del usuario del sistema ya que cada uno tiene un nivel de acceso limitado, lo anterior para proteger la confidencialidad de los datos. Así mismo los datos que se obtienen tienen que estar acordes con la petición y ser consistentes en íntegros respecto a los almacenados en la base de datos. Los datos a recolectar deben tener coherencia respecto a lo que se necesita, usando las validaciones para asegurar que sean correctos. Se debe definir previamente que se va a mostrar y recolectar, donde y de que forma para cada una de las pantallas que se van desarrollar. Si desea ver un ejemplo dirigirse a el documento de descripción de pantallas: Caso de prueba videotienda Relación entre datos Es importante que el contenido de las interfaces a generar este previamente representado, ya que son las bases de la construcción y sin estas podrían presentarse información no valida, incompleta, desordenada o fuera de las expectativas del cliente. Hemos definido entonces un lenguaje para modelar la relación existente entre los datos, con el fin de especificar la descripción de cada una de las interfaces dependiendo de los datos que se necesitan y se quieren mostrara ante los usuario finales. Para mayor información dirigirse al documento Patrones para la descripción formal de interfaces de usuario Flujo de Páginas El flujo de paginas Para el flujo que se lleva a cabo en cada acción vamos a utilizar los diagramas de secuencia propuestos por UML, con la siguiente modificación: Los diagramas de secuencias comunes muestran el curso normal de un caso de uso, y su transito por cada una de las clases. En nuestro caso, en vez de clases las cajas representarán pantallas, por donde transitará el sistema para responder a un evento. Diagrama de Secuencia Modificado:

25 El diagrama de secuencia describirá el curso particular de eventos para cada uno de los casos de uso, mostrando la navegación a través de las pantallas definidas, incluyendo los autores y los eventos generados en dichas operaciones En el diagrama de secuencia se tiene los elementos: Pantalla X Pantallas: Dice a que pantalla se hace referencia. Actor: Persona que interactúa con la pantalla. Operador Acción: Describe un evento. Si desea ver un ejemplo diríjase al documento de descripción de pantallas. 4.2 Elementos de diseño de una interfaz grafica Los elementos de diseño de una interfaz grafica, son aquellos que hacen referencia a la presentación estética(distribución, colores, fuentes, etc) de cada una de las pantallas. Este diseño es necesario para enfocar a la persona encargada de la construcción de las paginas en el resultado que se desea alcanzar dejándole poca libertad, esto evitará contratiempos y mal entendidos Diseño estructural Una buena practica para el desarrollo de interfaces de gráficas en J2EE, es hacer un diseño estructural que consiste en realizar un esquema previo de cómo se van a visualizar cada una de las pantallas determinando componentes comunes y singulares en cada de ellas. Una de las ventajas de realizar este diseño es la identificación de elementos comunes que pueden ser utilizados en todas las pantallas, lo cual que mejora el tiempo de desarrollo.

26 Otra ventajas es que se le da uniformidad al sistema haciendo que este sea mas agradable estéticamente. Entre los elementos que se deben tener en cuenta en el diseño encontramos: Encabezado El encabezado se ubica en la parte superior de la pagina, por lo general contiene un logo o una imagen que identifique la aplicación, es recomendable utilizar frames para que esta imagen se cargue solo una vez Menú El menú es necesario para una navegabilidad rápida, se puede ubicar en varios lugares y debe ser accesible desde cualquier página. Es una buena practica de programación web el utilizar menús, para no tener que regresar a paginas y causar mayor demora Zona de Contenido La zona de contenido cambia constantemente, dependiendo de la operación requerida por el usuario, en esta zona se podrán visualizar el resto de paginas de la aplicación y a las que se pueda dirigir según el tipo de rol de usuario que este en interacción Hojas de Estilo Las hojas de estilo permiten que el diseño sea flexible, debido a que recogen un conjunto de características comunes a una serie de páginas web; así cuando convenga, cambiando una característica de la hoja de estilo automáticamente cambiará en todas las páginas web Componentes Un componente es un elemento que posee unas características definidas, las cuales sirven para el cumplimiento de un objetivo para el que fue creado. Los componentes a usarse deben ser definidos en el diseño estructural, algunos son comunes pero la gran mayoría son únicos para cada pagina. Al observar cuales se necesitan, también se debe tener en cuenta como van a configurarse, es decir como se van a manejar las validaciones y cuales se van a hacer. Al definir los componentes desde el comienzo se tiene la ventaja de que se tendrá estipulado lo que se necesita para el desarrollo de las pantallas, así no se incluirán componentes que no aporten, porque todos estarán cumpliendo con un objetivo. En el documento de Descripción de Pantallas y Navegabilidad se encuentra un ejemplo de cómo se definen las validaciones y los componentes necesarios para el caso de prueba.

27 4.2.3 Zona de Mensajes Esta zona se encarga de mostrar diferentes mensajes los cuales pueden se tipo: informativos, de error o éxito. La implementación de esta zona puede ser de varios maneras descritas a continuación: Panel de Mensajes: Consisten en un panel que aparece en consecuencia a un evento, mostrando el mensaje asociado que explica la razón de este; Este panel es independiente de la pagina involucrada y tiene un botón para continuar en la aplicación en el siguiente paso del flujo. Estilo de campos: Consisten en resaltar el campo don de hubo errores con el fin que usuario lo identifique para su posterior corrección, adicionalmente se usa un comentario en frente de este campo en colores llamativos que especifica la razón del error. Mensajes en la parte superior o inferior: Consiste en ubicar el mensaje en la parte superior o inferior de la pagina, donde se especifique que lo genero, ya sea la razón de un error o la confirmación exitoso de una operación. Vale aclarar que cualquiera de los diseños anteriores es valido y adicionalmente que se pueden hacer mezclas entre estos utilizando dos o los tres al mismo tiempo Diagrama de navegabilidad Este diagrama es una herramienta útil para identificar la navegabilidad que existe entre las pantallas especificadas para la aplicación. Se construye a partir del direccionamiento que se describe para cada una de las pantallas que se definieron en la etapa anterior. Para nuestro caso particular, este diagrama consta de 3 componentes fundamentales que son: P1 Etiqueta Representación de una pantalla Indica direccionamiento de una pantalla a otra Indica el evento que genero el direccionamiento Luego de la construcción de este diagrama se habrá terminado el uso de la metodología y se deberá comenzar el proceso de implementación de la aplicación.

28 5. Otros problemas Framework unificado para desarrollo de interfaces J2EE A continuación se presentaran algunos problemas que van mas allá del alcance del proyecto pero que son importantes en el desarrollo de aplicaciones en J2EE. 5.1 Seguridad En todos los desarrollos de software es de gran importancia la seguridad que deben tener estos frente a intrusos. La seguridad des software se puede asociar con la seguridad de información que básicamente se refiere a la protección de sistema de información contra accesos sin autorización o la modificación de información. Por ser los sistemas un desarrollo humano es muy probable que este quede con errores que no se identifiquen porque no afectan el funcionamiento normal para el que fueron creados, sin embargo siguen siendo errores y son estos los que se buscan por un atacante para generar problemas informáticos en los sistemas; Debido esto es necesario determinar una seguridad al sistema tratando de mitigar estos ataques. Existen muchas maneras de realizar seguridad en Software, entre ellos encontramos otro software probado y que se puede adquirir en el mercado que haga esta tarea o módulos creados por el programador del sistema que solucionen dicho problema. Es importante, e independiente de la manera como se valla a realizar la seguridad, que antes que todo se debe conocer los riesgos de seguridad que tiene el sistema en su contexto, una tarea del programador; Determinados estos riesgos, se debe proceder a identificar medidas de seguridad apropiadas que busquen solucionar de alguna manera los riesgos planteados, todo esto con el fin de buscar la mejor estrategia de seguridad para el sistema. 5.2 Reportes Por la filosofía y arquitectura de las aplicaciones J2EE los reportes se han convertido de gran utilidad en este tipo de desarrollos; crear reportes de manera fácil, rápida, y útil, es de gran aceptación para los clientes y usuarios finales y con la ventaja que desde un browser se puede acceder a tan importante información. En el mercado existen diferentes software que ayudan a el diseño y construcción de reportes, entre ellos Jasper Report 16 que lo caracteriza por ser open source y ofrecer soporte, servicios y entrenamiento de manera gratuita. 16 Jasper Reports open source:

29 5.3 Performance Software performance hace referencia a la capacidad de reducir el coste y fiabilidad de los sistemas, evitar defectos en las aplicaciones, detectar cuellos de botellas y mitigarlos, detectar y anticipar la caída de servicios entre otras acciones que busca este deseable estado del software. Hay muchas compañías que ofrecen servicios de aseguramiento de esta necesaria característica del software, claro a un costo, sin embargo si se realiza un correcto proceso de Ingeniería de Software la probabilidad de que el sistema tenga un buen rendimiento es mayor. 5.4 Integración con otro Software Las aplicaciones J2EE permiten integración con Software externo y diferente al generado con Java; el ejemplo mas común de esto es la utilización de Flash 17 en las interfaces gráficas, que cada día atrae a mas programadores, por su capacidad única en diseño estético de la interfaz y la no muy compleja unión con Java. Esta claro que hay otros Software que se construyeron con propósitos específicos y que podemos utilizar estas ventajas en nuestros desarrollos de Software gracias a la flexibilidad de este tipo de arquitecturas. 17 Flash: Software desarrollado por la compañia Macromedia:

Sistema para el alquiler, control de películas y clientes en una videotienda

Sistema para el alquiler, control de películas y clientes en una videotienda CASO DE PRUEBA: Sistema para el alquiler, control de películas y clientes en una videotienda Documento de arquitectura Y servicios Versión Historia de Revisión Fecha Versión Descripción Responsable

Más detalles

Anexo 4 Documento de Arquitectura

Anexo 4 Documento de Arquitectura Anexo 4 Documento de Arquitectura 1. Introducción El anexo se describe el propósito y alcance referentes al proyecto correspondiente al documento de arquitectura. 2. Propósito El propósito del anexo de

Más detalles

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

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

Más detalles

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

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

Más detalles

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

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

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

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

Aplicación de Gestión y Web para un criadero/residencia canino. Índice. 1 Presentación...2. 2 Objetivos y trabajo realizado...2. 3 Conclusiones...

Aplicación de Gestión y Web para un criadero/residencia canino. Índice. 1 Presentación...2. 2 Objetivos y trabajo realizado...2. 3 Conclusiones... Índice 1 Presentación...2 2 Objetivos y trabajo realizado...2 3 Conclusiones...6 1 1 Presentación Actualmente existen muchas y variadas aplicaciones de gestión para cualquier tipo de negocio pero en cambio,

Más detalles

1 Índice... 1. 2 Introducción... 2. 2.1 Propósito... 2. 2.2 Alcance... 2. 3 Modelo Arquitectónico Inicial... 3

1 Índice... 1. 2 Introducción... 2. 2.1 Propósito... 2. 2.2 Alcance... 2. 3 Modelo Arquitectónico Inicial... 3 1 Índice 1 Índice... 1 2 Introducción... 2 2.1 Propósito... 2 2.2 Alcance... 2 3 Modelo Arquitectónico Inicial... 3 3.1 Diagrama de alto nivel de la arquitectura... 3 3.2 Vista de Casos de Uso... 5 3.2.1

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

Más detalles

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos 1. Introducción Curso académico 2009-2010 La práctica de Integración de Sistemas consiste en el diseño

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

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

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

Documento de Arquitectura de Software IEEE-1471-2000

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

Más detalles

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

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

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012 TFC J2EE Aplicación Web para la gestión de facturación de una empresa de cerrajería Sara Gutiérrez Melero ITIG Junio de 2012 Consultor: Jose Juan Rodriguez Índice 1. Introducción Objetivos Planificación

Más detalles

UNIVERSIDAD TÉCNICA DEL NORTE. Sistema Informático basado en tecnologías opensource para apoyo y gestión de Transportes del Norte

UNIVERSIDAD TÉCNICA DEL NORTE. Sistema Informático basado en tecnologías opensource para apoyo y gestión de Transportes del Norte UNIVERSIDAD TÉCNICA DEL NORTE Sistema Informático basado en tecnologías opensource para apoyo y gestión de Transportes del Norte MAGALY FUERTES MENESES FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS CARRERA

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

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

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Plan de Desarrollo de Software Universidad

Más detalles

Diseño del Sistema de Información

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

Más detalles

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

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

Más detalles

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

Análisis y diseño del sistema CAPÍTULO 3

Análisis y diseño del sistema CAPÍTULO 3 Análisis y diseño del sistema CAPÍTULO 3 36 CAPÍTULO 3 Análisis y diseño del sistema En este capítulo se pretende realizar un análisis detallado de los requerimientos del software a desarrollar para la

Más detalles

Rational Unified Process (RUP)

Rational Unified Process (RUP) Rational Unified Process (RUP) Este documento presenta un resumen de Rational Unified Process (RUP). Se describe la historia de la metodología, características principales y estructura del proceso. RUP

Más detalles

Herramienta de Gestión Integral de E-Business

Herramienta de Gestión Integral de E-Business Herramienta de Gestión Integral de E-Business Ingeniería técnica de informática de sistemas Autor: David López Martín Tutor: Antoni Oller Arcas Índice Introducción Metodología Análisis Diseño Planificación

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

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio Otro camino para el BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 El BPM El BPM (Business Process Management) no es solo una tecnología, además a grandes rasgos es una disciplina

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

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

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

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

http://www.informatizate.net

http://www.informatizate.net http://www.informatizate.net Metodologías De Desarrollo De Software María A. Mendoza Sanchez Ing. Informático - UNT Microsoft Certified Professional - MCP Analísta y Desarrolladora - TeamSoft Perú S.A.C.

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

Criterios de clasificación

Criterios de clasificación Criterios de clasificación Usualmente clasificamos para agrupar elementos con características comunes, simplificando la realidad y analizando un conjunto de elementos desde distintos puntos de vista. Sobre

Más detalles

SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB]

SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB] Gobierno Municipal del Cantón Bolívar. SOLUCIÓN DE UNA INTRANET BAJO SOFTWARE OPEN SOURCE PARA EL GOBIERNO MUNICIPAL DEL CANTÓN BOLÍVAR [IOS-GMCB] Visión Universidad Técnica del Norte Histórico de Revisiones

Más detalles

Programación Orientada a Objetos Analista Programador Universitario Plan 2008 Año 2010

Programación Orientada a Objetos Analista Programador Universitario Plan 2008 Año 2010 INTRODUCCION Los objetos usados en aplicaciones JAVA mantienen su estado y comportamiento mientras la aplicación se halle en ejecución. Generalmente se necesita mantener el estado y comportamiento de los

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

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

Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera. Departamento de Lenguajes y Sistemas Informáticos

Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera. Departamento de Lenguajes y Sistemas Informáticos Recomendaciones para la realización de la Documentación del Proyecto de Fin de Carrera Departamento de Lenguajes y Sistemas Informáticos INDICE 1. Introducción. 2. Documentación del Proyecto de Fin de

Más detalles

Visión General GXflow. Última actualización: 2009

Visión General GXflow. Última actualización: 2009 Última actualización: 2009 Copyright Artech Consultores S. R. L. 1988-2009. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento explícito de

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

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

Más detalles

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

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

Más detalles

EJ-DSI. Ejemplo - Diseño del Sistema de Información

EJ-DSI. Ejemplo - Diseño del Sistema de Información EJ-DSI Ejemplo - Diseño del Sistema de Información 1 Estructura DSI 1 Definición de la Arquitectura del Sistema DSI 2 Diseño de la arquitectura de soporte DSI 3 Diseño de Casos de Uso Reales DSI 4 Diseño

Más detalles

Introducción a la Ingeniería de Software - Examen 20/07/2012

Introducción a la Ingeniería de Software - Examen 20/07/2012 Cada pregunta múltiple opción contestada correctamente tiene un valor de 2,5 puntos. Esta parte consta de 20 preguntas, haciendo un total de 50 puntos. Los ejercicios de desarrollo tienen un valor total

Más detalles

CAPITULO I. MARCO TEORICO

CAPITULO I. MARCO TEORICO 1 CAPITULO I. MARCO TEORICO 1.1 DEFINICIÓN DEL PROYECTO. Para la definición del proyecto nos basaremos en una metodología de gestión de proyectos, para esto compararemos las características de tres de

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

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

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

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

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

PFC- Aplicaciones Web para trabajo colaborativo:

PFC- Aplicaciones Web para trabajo colaborativo: PFC- Aplicaciones Web para trabajo colaborativo: Aplicación para Control de una Integración de S.I. 2º Ciclo Ingeniería Informática Curso 2011-2012 Consultor : Fatos Xhafa Autor : Miguel Angel Pineda Cruz

Más detalles

Licencia 2: (Creative Commons)

Licencia 2: (Creative Commons) Licencia 2: (Creative Commons) Esta obra está bajo una licencia Reconocimiento-No comercial-sin obras derivadas 2.5 España de Creative Commons. Puede copiarlo, distribuirlo y transmitirlo públicamente

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

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo.

GLOSARIO. Arquitectura: Funcionamiento, estructura y diseño de una plataforma de desarrollo. GLOSARIO Actor: Un actor es un usuario del sistema. Esto incluye usuarios humanos y otros sistemas computacionales. Un actor usa un Caso de Uso para ejecutar una porción de trabajo de valor para el negocio.

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

Arquitectura de Aplicaciones

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

Más detalles

TFC. Ingeniería de Software MEMORIA. Consultor: Juan José Cuadrado Gallego

TFC. Ingeniería de Software MEMORIA. Consultor: Juan José Cuadrado Gallego TFC Ingeniería de Software Alumno: Halyna Klachko Consultor: Juan José Cuadrado Gallego Índice 1. Identificación del proyecto..5 1.1 Introducción...5 1.2 Objetivos del proyecto..5 1.3 Descripción general..5

Más detalles

El Proceso Unificado

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

Más detalles

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

Desarrollo de software

Desarrollo de software Agenda 1. Introducción 2. Aspectos Metodológicos del Desarrollo de Software 3. Aplicación Web (Modelo del Producto) 4. Modelo del proceso 5. Dos enfoques Metodológicos 6. Métodos Seleccionados 7. Evaluación

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

Ciclo de vida del Software

Ciclo de vida del Software Tema 2: Ciclo de vida del Software Marcos López Sanz Índice Qué es el ciclo de vida del Software? La norma 12207-2008 Modelos de desarrollo Qué es el Ciclo de Vida del SW? Es una sucesión de etapas por

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

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Introducción Este documento recopila las preguntas, opiniones y respuestas que se produjeron en un pequeño curso sobre las

Más detalles

IMPLEMENTACION DE SISTEMAS DE INFORMACION CONTABLE

IMPLEMENTACION DE SISTEMAS DE INFORMACION CONTABLE IMPLEMENTACION DE SISTEMAS DE INFORMACION CONTABLE OBJETIVO: Obtener los conocimientos necesarios para realizar implementación de sistemas contables CICLO DE VIDA DE UN SISTEMA DE INFORMACION MANTENIMIENTO

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

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

Universidad de Cantabria Facultad de Ciencias Ingeniería en Informática Ingeniería del Software I. Ejemplo Completo de Análisis y Diseño

Universidad de Cantabria Facultad de Ciencias Ingeniería en Informática Ingeniería del Software I. Ejemplo Completo de Análisis y Diseño Universidad de Cantabria Facultad de Ciencias Ingeniería en Informática Ingeniería del Software I Ejemplo Completo de Análisis y Diseño Este documento es un extracto formado por algunas partes del Proyecto

Más detalles

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

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

Más detalles

Introducción En este apartado se va a proporcionar una apreciación global del SRS.

Introducción En este apartado se va a proporcionar una apreciación global del SRS. INTRODUCCIÓN Se pretende desarrollar una aplicación web para la gestión de un restaurante que ofrece espectáculos en fechas determinadas con el fin de poner en práctica los principios de planificación

Más detalles

Planificación y Control de Proyectos de Software mediante MS Project

Planificación y Control de Proyectos de Software mediante MS Project Práctica 2 Planificación y Control de Proyectos de Software mediante MS Project E n esta práctica vamos a introducirnos en la Planificación y Control de Proyectos de Software mediante herramientas informáticas

Más detalles

ACCESS 2010 OFIMÁTICA AULA MENTOR

ACCESS 2010 OFIMÁTICA AULA MENTOR ACCESS 2010 OFIMÁTICA AULA MENTOR Módulo I: Introducción UNIDADES DIDÁCTICAS: 1. Unidad didáctica 1 2 Introducción a las Bases de Datos 2. Unidad didáctica 2 10 Comenzar a trabajar con Access Página 1

Más detalles

CAPÍTULO 5. DESARROLLO Y PRUEBAS

CAPÍTULO 5. DESARROLLO Y PRUEBAS CAPÍTULO 5. DESARROLLO Y PRUEBAS 5.1 Introducción a las Tecnologías 5.1.1 Herramientas 5.1.1.1 SQL Server Es un sistema que sirve para la gestión de base de datos basado en un modelo relacional. Así mismo

Más detalles

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

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

Más detalles

Javier Velásquez Maldonado velasquezj7@hotmail.com. Jhoanna Isabel Lansinot Tocain jlansinot@yahoo.com

Javier Velásquez Maldonado velasquezj7@hotmail.com. Jhoanna Isabel Lansinot Tocain jlansinot@yahoo.com DISEÑO, DESARROLLO E IMPLANTACIÓN DE UNA APLICACIÓN WEB PARA LA AUTOMATIZACIÓN DE LA INFORMACIÓN DE LA IGLESIA EVANGÉLICA INDÍGENA ECUATORIANA DE LA ALIANZA CRISTIANA Y MISIONERA. Javier Velásquez Maldonado

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

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

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

Más detalles

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

PEEPER PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS. Mayo 2014. Versión 2.1 OSCAR IVAN LÓPEZ PULIDO

PEEPER PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA DE INGENIERIA DE SISTEMAS. Mayo 2014. Versión 2.1 OSCAR IVAN LÓPEZ PULIDO PEEPER Implementación del cambio de técnica usada para la actualización de datos en los reportes de esfuerzo, usados como métrica de productividad, progreso y costo de los proyectos, de la compañía de

Más detalles

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar

Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Gobierno Municipal del Cantón Bolívar Gobierno Municipal del Cantón Bolívar Versión: Solución de una Intranet bajo software Open Source para el Gobierno Municipal del Cantón Bolívar [IOS-GMCB] Caso de Desarrollo Universidad Técnica del

Más detalles

Análisis de Requisitos

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

Más detalles

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

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

Más detalles

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

ARQUITECTUA DE M2M MIGUEL ÁLVAREZ Y CLARA HERRERO. Documento inicial

ARQUITECTUA DE M2M MIGUEL ÁLVAREZ Y CLARA HERRERO. Documento inicial Título ARQUITECTUA DE M2M Proyecto Monkey to Monkey ( M 2 M ) Equipo Proyectos Informáticos Versión 1.0 Código PLAN_M2M_2012_04_01 Fecha 19/04/2012 Autores MIGUEL ÁLVAREZ Y CLARA HERRERO Estado Documento

Más detalles

Especificación de requerimientos

Especificación de requerimientos Especificación de requerimientos 1. Requerimientos funcionales y no funcionales 2. Especificación de requerimientos en lenguaje natural 3. Herramientas de especificación Modelado de datos Diagramas entidad/relación

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

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes Capítulo 4 Arquitectura para análisis de información propuesta 4.1 Arquitectura Zombi es una arquitectura que proporciona de manera integrada los componentes necesarios para el análisis de información

Más detalles

SIGPRE Sistema de Gestión Presupuestaria

SIGPRE Sistema de Gestión Presupuestaria SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009

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

Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico

Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico Curso académico 2008-2009 1 Introducción La práctica de Integración de Sistemas consistirá en el diseño e implementación de

Más detalles

Rafael Doña Gil. Enginyeria Tècnica en Informàtica de Sistemes. Consultor: Jose Juan Rodríguez

Rafael Doña Gil. Enginyeria Tècnica en Informàtica de Sistemes. Consultor: Jose Juan Rodríguez Rafael Doña Gil Enginyeria Tècnica en Informàtica de Sistemes Consultor: Jose Juan Rodríguez 14 de Enero de 2013 Contenido 1. Introducción 2. Análisis funcional 3. Diseño Técnico 4. Implementación 5. Conclusiones

Más detalles

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m.

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m. Arquitecto de Datos 1. Línea de Negocios: Soluciones de Negocios 2. Funciones Específicas: Participar en la realización de las actividades técnicas de actualización y migraciones a versiones mejoradas

Más detalles

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Documento de trabajo elaborado para la Red Temática DocenWeb: Red Temática de Docencia en Control mediante Web (DPI2002-11505-E)

Más detalles

GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS TABLA DE CONTENIDO

GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS TABLA DE CONTENIDO - 1 - RUP/Easy GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS Setiembre 2004 TABLA DE CONTENIDO 1 INTRODUCCIÓN...1 2 ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP...2 2.1 WORKFLOWS ESENCIALES DEL RUP...2

Más detalles

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

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

Más detalles