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

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

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

Transcripción

1 - 1 - RUP/Easy GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS Setiembre 2004 TABLA DE CONTENIDO 1 INTRODUCCIÓN ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP WORKFLOWS ESENCIALES DEL RUP VISTA GENERAL DEL WORKFLOW DEL RUP PROCEDIMIENTOS DE REVISIÓN LA VERSIÓN RUP/E DE LOS WORKFLOWS ESENCIALES DEL RUP MODELAMIENTO DE NEGOCIOS REQUERIMIENTOS ANÁLISIS Y DISEÑO IMPLEM ENTACIÓN PRUEBAS DESPLIEGUE ADMINISTRACIÓN DE CONFIGURACIÓN Y CAMBIOS PASOS SIGUIENTES PARA LAS EMPRESAS CLIENTE...17 GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS 1 INTRODUCCIÓN Durante los últimos años, una de las metodologías más populares ha sido el Rational Unified Process (RUP). RUP, desarrollado por Rational Software Corporation, es un proceso de ingeniería de software que ofrece un enfoque disciplinado para asignar tareas y responsabilidades dentro de la organización del desarrollo. RUP captura algunas de las mejores prácticas de la industria para el desarrollo de software las cuales son para desarrollar el software en iteraciones, administrar requerimientos, usar arquitecturas basadas en componentes, verificar la calidad del software, controlar los cambios al software y modelar el software visualmente usando el Unified Modeling Language (UML). "El Unified Modeling Language (UML) es un método orientado a objetos y el lenguaje estándar de la industria para especificar, visualizar, construir y documentar los artefactos de sistemas de software.".

2 - 2 - Este documento presenta los pasos para aplicar correctamente la metodología RUP en el proceso de desarrollo de software. RUP es muy amplio y la mayoría de proyectos no necesitan seguir todo lo que está en el RUP. Esta guía presenta la variación hecha en el RUP denominada RUP/E para su aplicación en las empresas del Perú. 2 ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP Esta sección explica cómo leer la adecuación de los Workflows esenciales del RUP detallados en la sección 3 de este documento. 2.1 WORKFLOWS ESENCIALES DEL RUP Esta guía metodológica cubre la adecuación para siete (7) de los nueve (9) workflows : Modelamiento de Negocios, Requerimientos, Análisis y Diseño, Implementación, Pruebas, Administración de Configuración y Cambios y Despliegue. Esta guía metodológica excluye los workflows esenciales del RUP para Administración de Proyectos y Entorno. Estos workflows, los cuales variarán de acuerdo a las políticas, procedimientos y operaciones de cada empresa cliente interesada, serán revisados separadamente. 2.2 VISTA GENERAL DEL WORKFLOW DEL RUP La Sección 3 da una vista general a cada Workflow esencial del RUP y explica por qué es importante incluir ése particular Workflow esencial del RUP en su ciclo de vida de desarrollo de software.. Se presenta cada Workflow de Detalle dentro del Workflow esencial del RUP y es explicado al igual que los artefactos clave producidos por cada Workflow de detalle. Cada workflow descrito en la Sección 3 contiene las siguientes subsecciones: Configuración y Notas sobre el Workflow del RUP Artefactos Reportes Configuración y Notas sobre el Workflow del RUP Estas subsecciones detallan los cambios aplicados a la estructura de workflows del RUP en la variación de la metodología de RUP/E Artefactos Un artefacto es un pedazo de información que es creado, modificado o usado por un proceso tal como un modelo, un caso de uso, un documento, código fuente o un archivo ejecutable. Estas subsecciones listan los artefactos que deberían ser producidos por cada Workflow esencial del RUP en un formato de tabla. RUP provee templates, guías y ejemplos para todos los artefactos. Si usted no está usando RUP, entonces deberán desarrollarse los templates que puedan ser usadas en toda su organización para lograr

3 - 3 - consistencia al capturar el mismo tipo de información. La Tabla 2 identifica las columnas usadas para definir los artefactos producidos por cada workflow del RUP; las entradas en las columnas son explicadas en la Tabla 1. Tabla 1. Artefacto RUP Artefactos Created/Revised Revisar Detalles Herramientas Usadas RUP Artefacto 1 Incep Elab Const Trans Explicación de la Tabla Artefacto RUP La Tabla 2 da una explicación de las columnas en la Tabla Artefacto RUP mostrada en la Tabla 1. Tabla 2. Explicación de la Tabla Artefacto RUP Nombre de Columna Propósito Contenidos/Comentarios Artefactos El nombre del artefacto. Un artefacto es un entregable del proceso. Una referencia al artefacto en el Rational Unified Process. Creado / Revisado Califica cómo es usado el artefacto a través del ciclo de vida Revisar Detalles Define el nivel de revisión; procedimientos de revisión que van a ser aplicados al artefacto. Herramientas Usadas Definición de la herramienta (o herramientas) usadas para producir el artefacto. Una 'X' en una o más de las celdas Fase, significa que planeamos congelar ese artefacto en esa fase particular: Incepción, Elaboración, Construcción y Transición. Decidir el nivel de revisión: Formal-Externo Formal-Interno Informal Ninguno Para detalles vea la Sección 2.3, Procedimientos de Revisión Referencia a los detalles de las herramientas usadas para desarrollar y mantener el artefacto Reportes Esta subsección lista los reportes a ser usados por cada Workflow esencial del RUP. La Tabla 3 muestra el formato que es usado para definir los reportes producidos por cada Workflow esencial del RUP. Tabla 3. Tabla de Reportes Reportes Herramientas usadas 2.3 PROCEDIMIENTOS DE REVISIÓN

4 - 4 - Durante el ciclo de vida de un proyecto, una revisión de un artefacto o conjunto de artefactos es presentada al usuario, cliente u otras partes interesadas para comentarios y aprobación. Cuando se hacen estas revisiones, usted debe tener en consideración que las revisiones para el equipo de desarrollo de casa son diferentes a las revisiones para el equipo de desarrollo de un contratista. Si las revisiones son de casa mayormente son informales. Cuando el trabajo lo hace un contratista normalmente se hace una revisión formal del trabajo del contratista. RUP/E ha adoptado los niveles de revisión indicados en la Tabla 4. Tabla 4. Guías de Niveles de Revisión del RUP Nivel de Revisión Explicación Comentarios Formal-Externo Formal-Interno Informal Ninguno Este artefacto es un entregable en un hito específico. Requiere algún tipo de aprobación del cliente, el patrocinador o algún otro stakeholder externo. El artefacto es revisado formalmente por el equipo del proyecto. El artefacto es revisado; pero no es aprobado formalmente. Este artefacto no necesita ser revisado ni aprobado. Por ejemplo, la Visión y el Caso del Negocio son artefactos que deberían ser revisados por stakeholders. Los resultados de la revisión son manejados en la configuración junto con el artefacto. Por ejemplo, las interfases de diseño de subsistemas deberían ser revisados y aprobados por varios miembros del equipo del proyecto. Los resultados de la revisión son manejados en la configuración junto con el artefacto. Las Clases de Diseño y los Componentes son ejemplos de artefacto que no son aprobados formalmente. El artefacto es desarrollado y mantenido. Normalmente no es descartado luego que el proyecto termina. Los resultados de la revisión no son manejados en la configuración con el artefacto. El artefacto es creado como información de trabajo. A menudo es un artefacto temporal que es descartado luego que el proyecto termina. 3 LA VERSIÓN RUP/E DE LOS WORKFLOWS ESENCIALES DEL RUP La suite de herramientas de Rational (Rational Rose, RequisitePro, Rational Robot, ClearCase, ClearQuest) y el RUP, desarrollados por Rational Software, fueron escogidos para demostrar un enfoque iterativo del ciclo de vida de desarrollo de software. RUP/E usó el marco metodológico del RUP para adecuar los siguientes Workflows esenciales del RUP : Modelamiento de Negocios Una técnica de análisis para modelar los procesos del negocio y entender mejor las complejidades de éste. Requerimientos Una condición o capacidad que el sistema debe cumplir. Análisis y Diseño - Muestra cómo los casos del uso del sistema se realizarán en la implementación. Implementación Implementar y probar las clases.

5 - 5 - Pruebas Integrar y probar el sistema. Despliegue Asegura una transición exitosa del sistema desarrollado a sus usuarios. Administración de la Configuración y Cambios Identifica, define y estandariza ítems; controla las modificaciones y releases de ítems. Las organizaciones necesitarán incluir administración de proyectos con RUP y adecuarse según sea necesario. Un Plan de Iteración es algo que debe ser producido durante la administración del proyecto. 3.1 MODELAMIENTO DE NEGOCIOS El Modelamiento de Negocios se efectúa para valorar el negocio para el cual el sistema de información se está construyendo y para determinar mejor las necesidades y problemas a ser resueltos por los sistemas de información. Los modelos del negocio proveen una base para la comunicación entre los analistas de sistemas y los desarrolladores para incrementar su entendimiento del negocio y para identificar oportunidades de mejorar el negocio. También, los gerentes de proyecto usan los modelos del negocio para ayudarse a estimar los costos del proyecto. El Modelamiento del Negocio debería hacerse antes del desarrollo de software para obtener un buen entendimiento de sus procesos del negocio. Sin embargo, el Modelamiento del Negocio sólo debe ser efectuado si se está cambiando la manera en que se hace negocio. Si sólo se está añadiendo una nueva característica a un sistema existente, entonces RUP/E no recomienda que usted empiece con un modelamiento del negocio. En ese caso, RUP/E recomienda que usted empiece con la Sección 3.2, Requerimientos. 3.2 REQUERIMIENTOS Se debería manejar las generaciones (versiones) de requerimientos y su documentación. La Administración de Requerimientos incorpora la identificación, organización y documentación de los cambios a los requerimientos en un proyecto. Es una parte integral de la actividad de desarrollo de software. La Administración de Requerimientos establece un entendimiento común y acuerdo entre el cliente y el equipo del proyecto acerca de los requerimientos del cliente. Una Administración de Requerimientos efectiva incluye el mantener requerimientos claros. Mantener atributos acerca de los requerimientos (tales como estado, prioridad), proveer seguimiento a otros requerimientos y componentes y, proveer de los recursos adecuados y fondos para administrar los requerimientos Vista general del Workflow de Requerimientos El propósito del Workflow de Requerimientos es : Establecer y mantener acuerdos con los clientes y otros stakeholders acerca de lo que el sistema debe hacer Proveer a los desarrolladores del sistema con un mejor entendimientos de los requerimientos del sistema Definir las fronteras del sistema (delimitarlo)

6 - 6 - Proveer de una base para planificar el contenido técnico de la iteraciones Proveer de una base para estimar el costo y el tiempo para desarrollar el sistema Definirle al sistema una interfase para el usuario enfocándose en las necesidades y objetivos de los usuarios Los artefactos clave a desarrollar son : Visión, Modelo de Casos de Uso, Casos de Uso y Especificaciones Suplementarias. Estos artefactos describen lo que el sistema debe hacer. El Workflow de Requerimientos está relacionado a otros workflows del RUP : El Workflow de Modelamiento de Negocios (no considerado en la presente guía) provee las reglas del negocio y un modelo de caso de uso del negocio. El input principal para el Workflow de Análisis y Diseño son el Modelo de Casos de Uso y el Glosario creados durante el Workflow de Requerimientos. Por las fallas que se descubran en el Modelo de Casos de Uso, se generará requerimientos de cambio. El Workflow de Pruebas prueba el sistema para verificar el código contra el Modelo de Casos de Uso, los Casos de Uso y las Especificaciones Suplementarias. El Workflow de Administración de la Configuración y Cambios provee los mecanismos de control de cambios para los requerimientos. Los workflows de Requerimientos consisten de los siguientes workflows de detalle : Analizar el Problema El documento Visión es el principal artefacto en el cual el análisis del problema es documentado. Entender las Necesidades del Stakeholder El artefacto principal es un documento refinado de la Visión. También los requerimientos son discutidos y expresados en términos de Casos de Uso y Actores. Los requerimientos no funcionales, que no caen fácilmente en el Modelo de Casos de Uso deberán ser documentados en los documentos de Especificaciones Suplementarias. Definir el Sistema En Definir el Sistema, se enfoca en identificar a los actores y los casos de uso más completamente y expandir los requerimientos no funcionales definidos en los documentos de especificaciones suplementarias. Administrar el Alcance del Sistema El alcance del proyecto es definido por el conjunto de requerimientos definidos para éste. La clave para manejar un proyecto exitoso es administrar el alcance del proyecto para cumpliendo con los recursos disponibles tales como el tiempo, la gente y el dinero. Los atributos de requerimientos, tales como prioridad, esfuerzo y riesgo, son una técnica útil para manejar el alcance del proyecto.

7 - 7 - Refinar la Definición del Sistema El output de este Workflow del RUP es una comprensión más profunda de la funcionalidad del sistema expresada en Casos de Uso detallados y documentos de Especificaciones Suplementarias detallados. Si es necesario, una Especificación de Requerimientos de Software formal puede ser desarrollado, además de los documentos detallados de Casos de Uso y Especificaciones Suplementarias. Administrar los Requerimientos de Cambios Los cambios a los requerimientos impactan los modelos producidos en el Workflow de Análisis y Diseño, el modelo de pruebas creado en el Workflow de Pruebas y el material de soporte al usuario final del Workflow de Despliegue. Las relaciones de rastreabilidad son establecidas para identificar las relaciones entre los requerimientos y otros artefactos. Las relaciones de rastreabilidad son la clave para entender el impacto del cambio de los requerimientos Configuración y Notas sobre el Workflow de Requerimientos Cada actividad en el Workflow de Requerimientos es esencial para una implementación exitosa. Ninguna actividad debe ser removida del Workflow de Requerimientos Artefactos de Requerimientos Los Artefactos de Requerimientos capturan y presentan información usada en definir las capacidades requeridas por el sistema. La Tabla 7 identifica los artefactos que debe ser desarrollados cuando se captura los requerimientos del sistema. Tabla 7. Artefactos para el Workflow de Requerimientos Artefactos Creado / Revisaedo Revisar Detalles Herramientas Usadas Incep Elab Const Trans Actor X X Informal Rational Rose Glosario X X Formal-Externo Requisite Pro; MS Word Lista de Riesgos X Formal-Externo Requisite Pro Especificación Suplementaria X X Formal-Ext erno Requisite Pro; MS Word Caso de Uso X X Formal-Externo Rational Rose; Requisite Pro; MS Word Modelo de Caso de Uso X X Formal-Externo Rational Rose Vision Formal-Externo Requisite Pro; MS Word Reportes de Requerimientos La variación metodológica de RUP/E considera opcionales todos los reportes de requerimientos; sin embargo, si van a usarse, la Tabla 8 identifica los reportes que deben ser producidos durante el Workflow de Requerimientos. El Panorama del Modelo de Casos de Uso (Use-Case Model Survey) es muy comprensible y cubre la mayoría de la información contenida en los reportes de Actores y Casos de Uso.

8 - 8 - Tabla 8. Reportes para el Workflow de Requerimientos Reportes Panorama del Modelo de Caso de Uso Herramientas Usadas Rational SoDA; MS Word 3.3 ANÁLISIS Y DISEÑO El propósito del Workflow de Análisis y Diseño es empezar a realizar los casos de uso desarrollados durante el Workflow de Requerimientos. Es decir, tomar el Modelo de Casos de Uso, el Glosario y las Especificaciones Suplementarias creadas en el Workflow de Requerimientos y generar un modelo de diseño que pueda ser usado por los desarrolladores durante el Workflow de Implementación. El Análisis se enfoca en trasladar los requerimientos funcionales a conceptos de software Vista General del Workflow de Análisis y Diseño El propósito del Workflow de Análisis y Diseño es: Transformar los requerimientos en un diseño del sistema a crear Definir una arquitectura robusta para el sistema Adaptar el diseño para que funcione en el ambiente de implementación diseñándolo para obtener buena performance El Workflow de Análisis y Diseño toma los casos de uso documentados del Workflow de Requerimientos y del Workflow de Modelamiento de Negocios y los traslada a elementos de diseño que serán usados para construir el sistema. Por medio de usar varias actividades y modelos el Workflow de Análisis y Diseño busca destilar la información recogida de los stakeholders en información que los programadores podrán usar. Al final, un Modelo de Diseño, el documento de Arquitectura del Software, el Modelo de Despliegue y una Realización de Casos de Uso por cada Caso de Uso describirán el sistema. El Workflow de Análisis y Diseño está relacionado a otros workflow del RUP como sigue : El Workflow de Implementación usará el Modelo de Diseño, el Modelo de Despliegue, el documento de Arquitectura del Software y las Realizaciones de Casos de Uso como inputs en la construcción e implementación del sistema. El Workflow de Pruebas usará las realizaciones de casos de Uso y el documento de Arquitectura del Software para probar la funcionalidad y la compatibilidad de los componentes. El Modelo de Despliegue y el documento de Arquitectura del Software será usado por el Workflow de Despliegue para desplegar el sistema final. El Workflow de Análisis y Diseño consiste de los siguiente workflows de detalle:

9 - 9 - Definir una Arquitectura candidata Refinar la Arquitectura Analizar el Comportamiento Diseñar la base de Datos (Opcional) Configuración y Notas sobre el Workflow de Análisis y Diseño El Workflow de detalle Refinar la Arquitectura puede ser saltado si hay relativamente pocos riesgos arquitecturales. Esto es, el diseño, la implementación y la distribución del sistema no producen problemas arquitecturales significativos o el arquitecto de software tiene suficiente experiencia para manejar tales hechos. El Workflow de detalle Efectuar Síntesis Arquitectural puede ser saltado. Este Workflow de detalle puede ser efectuado si es que se necesita profundizar los conceptos. Los workflows de detalle Diseñar Componente de Tiempo Real y Diseñar Componente [No Tiempo Real] son similares con la excepción de que el primero se enfoca en componentes que son para sistemas en tiempo real y el otro para sistemas reactivos Artefactos para Análisis y Diseño Los Artefactos para Análisis y Diseño capturan y presentan información relativa a la solución de los problemas planteados durante el Workflow de Requerimientos. La Tabla 9 identifica los artefactos que deberán producirse durante el Workflow de Análisis y Diseño. Tabla 9. Artefactos para el Workflow de Análisis y Diseño Artefactos Creado / Revisado Revisar Detalles Herramientas Usadas Incep Elab Const Trans Modelo de Diseño X X X Formal - Externo Rational Rose Modelo de Datos X X Informal - Interno Rational Rose Documento de Arquitectura del Software Reportes para Análisis y Diseño X X X Formal - Externo RequistePro; MS Word La variación metodológica de RUP/E considera opcionales todos los reportes de requerimientos; sin embargo, si van a usarse, la Tabla 10 identifica los siguientes reportes opcionales : Tabla 10. Reportes para el Workflow de Análisis y Diseño Reportes Clase Panorama del Modelo de Diseño Rational SODA Rational SODA Herramientas Usadas

10 IMPLEMENTACIÓN La Implementación es donde empieza el código El Modelo de Diseño del Workflow de Análisis y Diseño es mapeado con el Modelo de Implementación y entonces se escribe el código en un lenguaje de programación tal como Java, C++ o Visual Basic. Un Plan de Integración de Construcciones define el Caso de Uso a ser diseñado y las clases a implementar, al igual que el orden en el que las clases son implementadas Vista general del Workflow de Implementación El propósito del Workflow de Implementación es: Definir la organización del código, en términos de Subsistemas de Implementación. Define the organization of the code, in terms of Subsistema de Implementación. Los Subsistemas de Implementación son colecciones de componentes y otros modelos de implementación usados para estructurar el modelo de implementación. Implementar las clases y objetos definidos en el modelo de diseño en la forma de componentes de software tales como archivos fuente, binarios o ejecutables Probar los componentes desarrollados como unidades Crear un sistema ejecutable El Workflow de Implementación está relacionado a otros workflows del RUP como sigue: Requerimientos: Este workflow del RUP captura los requerimientos que deberían ser cumplidos durante la Implementación. Análisis y Diseño: El modelo de diseño desarrollado durante este workflow representa el intento de la implementación y es el input principal para el Workflow de Implementación. Pruebas: Este workflow describe cómo probar cada Construcción durante la integración del sistema. Para cada iteración, empezando en la fase de Elaboración, se efectúan los siguientes workflows de detalle : Estructurar el Modelo de Implementación El artefacto principal producido es el Modelo de Implementación. Planificar la Integración El artefacto principal producido es el Plan de Integración de Construcciones. Según la arquitectura y el diseño evolucionan, el Plan de Integración de Construcciones es examinado y actualizado para asegurar que no quede obsoleto debido a los cambios en la arquitectura o en el diseño del nuevo sistema.

11 Implementar los Componentes La Implementación debería estar unida muy de cerca al Diseño. El artefacto principal producido es el Componente. Integrar cada Subsistema Los principales artefactos producidos son la Construcción y el Subsistema de Implementación. Integrar el Sistema La Integración a menudo envuelve un alto grado de automatización, experiencia en sistemas operativos o lenguajes script y herramientas como 'make' (en Unix). El artefacto principal producido es la Construcción Configuración y Notas sobre el Workflow de Implementación Cada actividad en el Workflow de Implementación es esencial para una implementación exitosa. Ninguna actividad debe removerse del Workflow de Implementación Artefactos para la Implementación Los Artefactos para la Implementación capturan y presentan la realización de la solución presentada en el Workflow de Análisis y Diseño. La Tabla 11 identifica los artefactos que deben producirse durante el Workflow de Implementación. Tabla 11. Artefactos para el Workflow de Implementación Artefactos Creado/Revisado Revisar Detalles Herramientas Usadas Incep Elab Const Trans Construcción X X X Formal - Externo Rational Rose Por este artefacto se entiende al Prototipo o Producto, según la fase en que se encuentre el proyecto, resultante de cada iteración Reportes para la Implementación Ningún reporte será producido durante el Workflow de Implementación. Sin embargo, se efectuarán revisiones informales del código. 3.5 PRUEBAS Rational ofrece su enfoque de pruebas usando el RUP para valorar la calidad del software por medio de: Encontrar y documentar los defectos en la calidad del software Aconsejando acerca de la calidad percibida en el software Proveyendo la validación de los supuestos hechos en las especificaciones de diseño y los requerimientos a través de demostraciones concretas Validando las funciones del producto de software según sean diseñadas

12 Validando que los requerimientos hayan sido implementados apropiadamente Vista General del Workflow de Pruebas El propósito de este workflow del RUP es: Verificar la interacción entre objetos Verificar la interacción apropiada de todos los componentes del software Verificar que todos los requerimientos hayan sido implementados correctamente Identificar y asegurar que los defectos se hayan atendido y resuelto antes del despliegue del software En el RUP, las pruebas son enfocadas a través del uso de un proceso iterativo y de herramientas. Un enfoque iterativo para probar permite a la organización tratar las pruebas casi de la misma forma que el desarrollo de software es enfocado. Cada Construcción de software es un objetivo para las pruebas. Según se vayan produciendo nuevas Construcciones, el cuerpo de pruebas será añadido y refinado. Eventualmente, todas las pruebas en el cuerpo de pruebas serán acumuladas de tal manera que pueden ser usadas para las posteriores pruebas de regresión en el ciclo de vida del desarrollo de software. Este enfoque permite a una organización identificar posibles riesgos al inicio de un proyecto, reducir el costo de corregir fallas enfocando los recursos cuando y donde tendrán el mayor impacto, acercarse a los gaps de calidad tempranamente en el proceso de desarrollo y maximizar la efectividad por medio de adaptar el enfoque, el proceso o el presupuesto según va progresando el proyecto. Este workflow del RUP está relacionado a otros workflows del RUP como sigue: El Workflow de Requerimientos captura el input principal para identificar cuales pruebas efectuar en la forma de requerimientos en un modelo de caso de uso. El Workflow de Análisis y Diseño captura el input principal para identificar cuales pruebas efectuar describiendo cómo desarrollar un diseño. El Workflow de Implementación produce las Construcciones de software del modelo de implementación que es probado por medio del Workflow de Pruebas. Dentro de una iteración, hay varias construcciones probadas: la primera cuando el sistema es integrado y la última para probar todo el sistema. El Workflow de Pruebas consiste de los siguientes Workflows de detalle: Planificar las Pruebas El principal artefacto producido es el Plan de Pruebas. Diseñar las Pruebas Los principales artefactos producidos son el Modelo de Pruebas (Test Model), los Casos de Prueba (Test Case), los Procedimientos de Prueba (Test Procedures) y el documento de Análisis de Carga de Trabajo (Workload Analysis Document).

13 Implementar las Pruebas Los principales artefactos producidos son el Script de la Prueba y el Componente de la Prueba. Ejecutar las Pruebas en la etapa de Integración de Pruebas El principal artefacto producido es el documento Resultado de Pruebas. Ejecutar las Pruebas en la etapa de Pruebas del Sistema El principal artefacto producido es el documento Resultado de Pruebas. Evaluar las Pruebas Los principales artefactos producidos son el Sumario de Evaluación de Pruebas (Test Evaluation Summary) y los Requerimientos de Cambio (Change Request) Configuración y Notas sobre el Workflow de Pruebas Cada actividad en el Workflow de Pruebas es esencial para probar exitosamente. Ninguna actividad debe ser removida del Workflow de Pruebas Artefactos de Pruebas Los artefactos presentados en la siguiente tabla son productos finales e intermedio que son producidos y usados durante el Workflow de Pruebas de un proyecto. Loas artefactos de Pruebas capturan y comunican información de pruebas y pueden tomar la forma de un documento, un modelo o un elemento de modelo. La Tabla 12 identifica los artefactos que deben ser desarrollados en el Workflow de Pruebas. Tabla 12. Artefactos para el Workflow de Pruebas Artefactos Creado / Revisado Revisar Detalles Herramientas Usadas Incep Elab Const Trans Caso de Prueba X Informal - Interno Test Manager Plan de Pruebas/ Procedimientos X X Formal - Externo o Prueba Interna Manager Resultados de las X X Formal - Interno Test Manager Pruebas Script de Pruebas X X X Informal - Interno Robot, Manual Test Reportes para las Pruebas Ningún reporte será producido durante Workflow de Despliegue. Los artefactos producen la necesaria información workflow del RUP. 3.6 DESPLIEGUE Una vez que el producto de software ha siso implementado y probado exitosamente, es

14 momento de llevar el producto al cliente. El propósito de este workflow del RUP es producir releases del producto y llevar el software a los usuarios finales Vista General del Workflow de Despliegue El Workflow de Despliegue implica probar el software en su ambiente operacional final, empacar el software para la entrega, distribuir el software, instalar el software, entrenar a los usuarios finales y convertirlas bases de datos anteriores para la carga de datos. Hay tres maneras de proveer del producto al usuario final: La instalación en el cliente Se entrega un instalador (generado con algún producto de compresión e instalación) Accesar al software por la Internet Cualquiera que sea el método escogido para entregar al cliente, la prueba del producto ocurre en el site de desarrollo seguido por la prueba Beta y finalmente liberando el producto al cliente. El Workflow de Despliegue está relacionado a otros workflows del RUP, como sigue: Planificar el Despliegue Desarrollar Material de Soporte Produce el material de soporte, el cual incluye instrucciones para instalación, operación y mantenimiento para el sistema desplegado. También incluye el material de entrenamiento para las diversas posiciones requeridas para usar el sistema efectivamente. Manejar las Pruebas de Aceptación Producir la Unidad de Despliegue Empaquetar el Producto Proveer Acceso al Site de Descarga Producto en Beta Configuración y Notas sobre el Workflow de Despliegue Las organizaciones grandes pueden empacar el producto y dar acceso a un site de descarga; sin embargo, la mayoría no necesita efectuar estos workflows de detalle Artefactos para el Despliegue Los artefactos de Despliegue capturan y presentan información relativa a posicionar el

15 sistema, presentado en el Workflow de Implementación, dentro del ambiente de producción. La Tabla 14 identifica los artefactos que deben ser producidos durante el Workflow de Despliegue. Tabla 14. Artefactos para el Workflow de Despliegue Artefactos Creado/Revisado Revisar Detalles Herramientas Usadas Incep Elab Const Trans Relación de Materiales X X Informal MS Word Plan de Despliegue X X X Informal MS Word Producto X Formal-Externo MS Word Notas del Release X Formal - Interno MS Word Materiales de Entrenamiento X X X Formal - Externo MS Word Por Materiales de Entrenamiento, se entenderá el Manual del Usuario y el Manual Técnico Reportes para el Despliegue Ningún reporte será producido durante Workflow de Despliegue. Los artefactos producen la necesaria información workflow del RUP. 3.7 ADMINISTRACIÓN DE CONFIGURACIÓN Y CAMBIOS La mayoría de equipos de desarrollo de software experimentados reconocen la necesidad del control de versiones de los artefactos del software. Parcialmente, a causa de que el software es tan fácil de cambiar, un proyecto está continuamente vulnerable a la introducción inadvertida de incompatibilidades (errores de regresión) y fallas resultantes de la aplicación a menos que una disciplina constante sea aplicada. El control de versiones, sin embargo, es sólo un componente de la Administración de Configuración y Cambios (Configuration & Change Management -CCM-). Un buen sentido de ordenamiento es provisto por esta lista de las mejores prácticas de CCM : Identificar y almacenar los artefactos en un repositorio seguro Controlar y auditar loa cambios a los artefactos Organizar los artefactos en componentes versionados Crear versiones congeladas (baselines) en los hitos del proyecto Registrar y rastrear los requerimientos de cambio Organizar e integrar juegos consistentes de versiones (algunas veces llamados actividades ) Mantener áreas de trabajo estables y consistentes (inclusive sobre sites distribuidos geográficamente) Soportar cambios concurrentes a los artefactos y componentes Integrar tempranamente y a menudo Asegurar que las Construcciones de software sean reproducibles RUP/E recomienda usar CRM (Change Requeriment Management) en todas las fases

16 del ciclo de vida después de la Incepción. Aunque CRM puede ser hecho manualmente, sus mayores beneficios se obtienen cuando se usa una herramienta automatizado para hacer uso de una base de datos. Existe un número de excelente herramientas de CRM. ClearQuest de Rational es una buena opción si planea integrarse con otras herramientas de Rational. Además de automatizar, lo que muchos consideran un proceso tedioso, una herramienta CRM manejada con una base de datos también provee otro gran beneficio : la habilidad de extraer información fácilmente acerca del progreso del proyecto, especialmente en las fases de Construcción y posteriores. Una buena herramienta de CRM permite que se pueda crear consultas ad-hoc fácilmente Vista general del Workflow de Administración de Configuración y Cambios El propósito de este workflow del RUP es: Soportar métodos de desarrollo Mantener la integridad del producto Asegurar que el producto configurado esté completo y correcto Proveer de un ambiente estable dentro del cual se desarrolla el producto Restringir los cambios a los artefactos basados en las políticas del proyecto Proveer pistas de auditoria de cambios a los artefactos registrando por qué, cuándo y por quién El Workflow de Administración de Configuración y Cambios está relacionado a otros workflows esenciales del RUPs (Modelamiento de Negocios, Requerimientos, Análisis y Diseño, Implementación, Pruebas, Despliegue) porque sirve como un repositorio para los artefactos producidos durante esos workflows del RUPs. Los artefactos clave son el Plan de Administración de Configuración (Configuration Management Plan) y los Requerimientos de Cambio (Change Request) Los siguientes Workflows de detalle de Administración de Configuración y Cambios son efectuados: Planificar la Configuración del Proyecto y el Control de Cambios El Plan CM describe todas las actividades a efectuarse durante el curso del ciclo de vida del proyecto. El Plan CM documenta cómo se planifica, implementa, controla y organiza las actividades relativas al CM del producto. Crear un Ambiente CM para el Proyecto Los desarrolladores e integradores son provistos de espacios de trabajo privados y compartidos donde puedan construir e integrar el software.

17 Cambiar y Enviar los Items de la Configuración Manejar Versiones Congeladas (Baselines) y Liberacioness Monitorear y Reportar el estado de la Configuración Administrar los Requerimientos de Cambio Notas sobre el Workflow de Administración de Configuración y Cambios Cada actividad en el Workflow de Administración de Configuración y Cambios es esencial para una administración de configuración exitosa. Ninguna actividad debe ser removida del Workflow de Administración de Configuración y Cambios Artefactos RUP de Administración de Configuración y Cambios Los artefactos e Administración de Configuración y Cambios capturan y presentan información relativa a las actividades CM. La Tabla 15 identifica los artefactos que deben ser producidos durante el Workflow de Administración de Configuración y Cambios. Tabla 15. Artefactos para la Administración de Configuración y Cambios Artefactos Creado/Revisado Revisar Detalles Herramientas Usadas Incep Elab Const Trans Requerimiento de Cambio X X X Informal Rational ClearQuest Repositorio del Proyecto X X X Ninguno Rational ClearCase Workspace X X X Ninguno Rational ClearCase 4 PASOS SIGUIENTES PARA LAS EMPRESAS CLIENTE La Sección 3 da una versión adecuada genérica del RUP usando la suite de herramientas de Rational; sin embargo, esto puede no cubrir las necesidades de cada empresa. Las empresas deberán hacer lo siguiente : Evaluar sus organizaciones para determinar cómo proveer del ambiente de desarrollo de software necesario para soportar a su equipo de desarrollo; este ambiente puede incluir las herramientas de la Suite de Rational u otras herramientas Comprar nuevo software, si es necesario Lograr la disponibilidad de usar la metodología de parte de la Administración Obtener el entrenamiento apropiado en el software usado Decidir si se desarrollará otros artefactos adicionales a los indicados en la Sección 3 Incluir un enfoque de administración de proyectos para : manejar riesgos planificar proyectos identificar métricas monitorear el progreso del proyecto y; manejar recursos, presupuestos y contratos con proveedores y clientes

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

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

RUP: Disciplina de Manejo de Cambios y Configuraciones

RUP: Disciplina de Manejo de Cambios y Configuraciones RUP: Disciplina de Preparado por: Amelia Soriano Mayo 2005 Tomado de: Rational Unified Process Version 2003.06.12.01 Copyright 1987 2003 Rational Software Corporation Curso Rational Unified Process Rational

Más detalles

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

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

Más detalles

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

6 Anexos: 6.1 Definición de Rup:

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

Más detalles

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

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

RUP. Rational Unified Process

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

Más detalles

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

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Plan de iteraciones RUP Proceso Iterativo e Incremental El ciclo de vida iterativo se basa en la evolución de prototipos ejecutables que se muestran a los usuarios y clientes (miniproyectos)

Más detalles

Introducción a Rational Unified Process (RUP)

Introducción a Rational Unified Process (RUP) Qué es un Proceso de Desarrollo de SW? Introducción a Patricio Letelier letelier@dsic.upv.es Departamento Sistemas Informáticos y Computación (DSIC) (UPV) - España Define Quién debe hacer Qué, Cuándo y

Más detalles

PUD: Proceso de Desarrollo Unificado

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

Más detalles

METODOLOGÍA DE GESTION DE PROYECTOS

METODOLOGÍA DE GESTION DE PROYECTOS METODOLOGÍA DE GESTION DE PROYECTOS CONTENIDO CONTENIDO... 2 ALCANCE... 4 MARCO METODOLÓGICO... 4 ETAPAS DEL PROCESO... 5 1. ETAPA 0: INICIACIÓN...5 FASE DE INICIO...5 2. ETAPA 1: PLANEAMIENTO...6 FASE

Más detalles

Mantenimiento del Software

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

Más detalles

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

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

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

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

Planeación del Proyecto de Software:

Planeación del Proyecto de Software: Apéndice A. Cuestionarios del Sistema Evaluador Nivel2. Requerimientos de Administración: Goal 1: Los requerimientos del sistema asociados a software están bien controlados y existe un estándar para los

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

IBM Software Development Platform

IBM Software Development Platform IBM Group IBM Development Platform Seminario. antonio.alonso@es.ibm.com IBM Group software Agenda 1. Introducir plataforma de desarrollo de IBM. 2. DEMO: Construcción de aplicaciones J2EE con RAD. 3. Café

Más detalles

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

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

Más detalles

Desarrollo y comercialización de productos de software [El proceso unificado]

Desarrollo y comercialización de productos de software [El proceso unificado] Desarrollo y comercialización de productos de software [El proceso unificado] M. en C. Sergio Luis Pérez Pérez UAM CUAJIMALPA, MÉXICO, D. F. Trimestre 13-P Sergio Luis Pérez (UAM CUAJIMALPA) Curso de desarrollo

Más detalles

INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS

INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS INGENIERÍA DE SOFTWARE CICLOS DE VIDA Y METODOLOGIAS Rubby Casallas, Andrés Yie Departamento de Sistemas y Computación Facultad de Ingeniería Universidad de los Andes Agenda Contexto Ciclos de vida: Modelo

Más detalles

1.1 Aseguramiento de la calidad del software

1.1 Aseguramiento de la calidad del software 1.1 Aseguramiento de la calidad del software El propósito del Aseguramiento de la Calidad (Software Quality Assurance, SQA) es entregar a la administración una visibilidad adecuada del proceso utilizado

Más detalles

Ingeniería del Software II

Ingeniería del Software II Bloque III: Proceso Unificado Simona Bernardi Dipartimento di Informatica Università di Torino (Italia) Duración: 4 horas Objetivo: Conocer un proceso de desarrollo de software diferente a OMT Simona Bernardi

Más detalles

Introducción al Unified Process. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010

Introducción al Unified Process. Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010 Introducción al Unified Process Curso IIC 2143 Ingeniería de Software Rodrigo Sandoval 2010 Unified Process - UP Un framework de Proceso de Desarrollo de Software, una de cuyas versiones es el más documentado

Más detalles

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS

UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS UNIVERSIDAD UNION BOLIVARIANA CARRERA DE INGENIERIA DE SISTEMAS METODOLOGIAS AGILES PROCESO UNIFICADO AGIL (AUP) MATERIA : INGENIERIA SOFTWARE DOCENTE : LIC. ERVIN FLORES ESTUDIANTE : JORGE LUIS CORDERO

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

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

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

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

Más detalles

Cuándo estoy listo para pasar a producción?

Cuándo estoy listo para pasar a producción? IBM Software Expo 2006. Madrid 23 de Mayo Cuándo estoy listo para pasar a producción? antonio.alonso @ es.ibm.com IBM Software 2005 IBM Corporation Agenda IBM Software Expo 2006. Madrid, 23 de mayo La

Más detalles

CAPÍTULO 1. MARCO TEÓRICO

CAPÍTULO 1. MARCO TEÓRICO CAPÍTULO 1. MARCO TEÓRICO Capítulo 1. Marco teórico 1.1 Ingeniería Web (IWeb) Con el desarrollo de Internet, la mayoría de los proyectos y sistemas están enfocados para las aplicaciones basadas en la Web

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

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

CAPÍTULO IV COMPARACIÓN DE LAS DOS PRINCIPALES HERRAMIENTAS ALM.

CAPÍTULO IV COMPARACIÓN DE LAS DOS PRINCIPALES HERRAMIENTAS ALM. CAPÍTULO IV COMPARACIÓN DE LAS DOS PRINCIPALES HERRAMIENTAS ALM. 4.1. ANÁLISIS COMPARATIVO DE LAS DOS HERRAMIENTAS ALM. Existen muchos factores que se debe tomar en cuenta al momento de elegir entre herramientas

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

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática

CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0. Centro Ideoinformática CONFIGURACIÓN DE LA METODOLOGÍA OPENUP V1.0 Centro Ideoinformática Universidad de las Ciencias Informáticas Carretera a San Antonio Km 2 ½. Torrens. Boyeros. Ciudad de La Habana. Cuba Teléfono: + 53 (7)

Más detalles

DESARROLLO DE SOFTWARE ORIENTADO. A OBJETOS: Modelo de requerimientos del RUP

DESARROLLO DE SOFTWARE ORIENTADO. A OBJETOS: Modelo de requerimientos del RUP DESARROLLO DE SOFTWARE ORIENTADO A OBJETOS: Modelo de requerimientos del RUP Adesmiro Zelada Escobedo 1*, Miguel Figueroa Martel 2 * 1 Facultad de Ingeniería y Arquitectura, Universidad Peruana Unión *

Más detalles

HERRAMIENTAS Y METODOLOGÍAS VERSIÓN 3

HERRAMIENTAS Y METODOLOGÍAS VERSIÓN 3 HERRAMIENTAS Y METODOLOGÍAS VERSIÓN 3 RESUMEN EJECUTIVO Herramientas y Metodologías Herramientas de Desarrollo o Desarrollo de aplicaciones Oracle Designer Oracle Software Configuration Manager (SCM) Oracle

Más detalles

Gestión del Portfolio de Proyectos HP Portfolio & Project Management. Información de Producto. 2010 Dirección de Consultoría

Gestión del Portfolio de Proyectos HP Portfolio & Project Management. Información de Producto. 2010 Dirección de Consultoría Gestión del Portfolio de Proyectos HP Portfolio & Project Información de Producto 2010 Dirección de Consultoría 2 1. Introducción Actualmente las organizaciones necesitan hacer frente a la complejidad

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

Nomenclador de cargos

Nomenclador de cargos Nomenclador de cargos ROLES Áreas de I T Definición de módulos y roles Versión: 1.0 Pagina 1 Módulos interactuantes en un área de IT 1. Infraestructura Tecnológica 2. Producción de Software 3. Asistencia

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

GIA Glosario. Versión 1.1

<Company Name> GIA Glosario. Versión 1.1 GIA Glosario Versión 1.1 Historial de revisiones Fecha Versión Descripción Autor 08/03/2010 1.0 Versión inicial para su aprobación Arturo Valdés Diéguez 18/03/2010 1.1 Revisión del documento

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

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

ITIL FOUNDATION V3 2011

ITIL FOUNDATION V3 2011 ITIL FOUNDATION V3 2011 Examen de Certificación Instrucciones 1. Revise su Hoja de Respuesta, debe contener espacio para responder 40 preguntas y una sección para incorporar su Nombre 2. Espere por la

Más detalles

Examen de Fundamentos de ITIL

Examen de Fundamentos de ITIL Examen de Fundamentos de ITIL Ejemplo B, versión 5.1 Selección Múltiple Instrucciones 1. Debe intentar contestar todas las 40 preguntas. 2. Marque sus respuestas en la hoja de respuestas entregada 3. Usted

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

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

Metodología para el diseño y desarrollo de interfaces de usuario Metodología para el diseño y desarrollo de interfaces de usuario Versión Historia de Revisión Fecha Versión Descripción Responsable 20/06/2005 Creación. Alejandro Báez Cristian Castañeda Diego

Más detalles

IBM Rational Method Composer V7.5.1 ofrece creación de métodos simplificados e interoperabilidad en IBM Rational Team Concert

IBM Rational Method Composer V7.5.1 ofrece creación de métodos simplificados e interoperabilidad en IBM Rational Team Concert con fecha 30 de noviembre de 2010 IBM Rational Method Composer V7.5.1 ofrece creación de métodos simplificados e interoperabilidad en IBM Rational Team Concert Índice 1 Información general 2 Fecha de disponibilidad

Más detalles

Aseguramiento de la calidad del software

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

Más detalles

Integración del PMBOK al RUP para proyectos de Desarrollo de Software

Integración del PMBOK al RUP para proyectos de Desarrollo de Software Integración del PMBOK al RUP para proyectos de Desarrollo de Software Fernando Torres UPG-FISI, Universidad Nacional Mayor de San Marcos (UNMSM), Av. German Amezaga s/n, Ciudad Universitaria, Lima, Perú

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

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

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

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

Más detalles

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE

3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE 3. GESTIÓN DE CONFIGURACIÓN DE SOFTWARE Software Configuration Management (SCM) es una disciplina de la Ingeniería de Software que se preocupa de [Ber92] [Ber84] [Bou98] [Mik97]: Identificar y documentar

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

Syllabus. www.techeraperu.com cursos@techeraperu.com

Syllabus. www.techeraperu.com cursos@techeraperu.com Syllabus www.techeraperu.com cursos@techeraperu.com Este curso está dirigido para los Encargados de Desarrollar los Sistemas de Información y aplicar una Metodología basada en RUP para controlar el Ciclo

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

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

Tema 3. Procesos ligeros de desarrollo de software.

Tema 3. Procesos ligeros de desarrollo de software. Ingeniería del Software II 2011 Tema 3. Procesos ligeros de desarrollo de software. Tipos de procesos ligeros. Tipos de procesos ligeros: Desarrollo Rápido de Software. Desarrollo Ágil. Programación Extrema.

Más detalles

K2BIM Plan de Configuración Versión 0.9

K2BIM Plan de Configuración Versión 0.9 K2BIM Plan de Configuración Versión 0.9 Historia de revisiones Fecha VersiónDescripción Autor 21/08/2009 0.1 Modificado el punto 2.2 Yasim Zeballos 23/08/2009 0.9 Completados la mayoría de los puntos.

Más detalles

Sistema PYMES Ventas e Inventarios H&S

Sistema PYMES Ventas e Inventarios H&S Sistema PYMES Ventas e Inventarios H&S Sistema PYMES Ventas e Inventarios H&S Visión DESARROLLADORA Teodora Vargas Tarqui Versión 0.9 Tabla de Contenidos 1. INTRODUCCION 3 1.1 Propósito 3 1.2 Alcance 3

Más detalles

Tema 5. Gestión de Proyectos (ISG3)

Tema 5. Gestión de Proyectos (ISG3) Tema 5. Gestión de Proyectos (ISG3) Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual - 2.5 - España 1 Planificación 1ª Clase: Presentación y Conceptos Generales 2ª Clase:

Más detalles

MINISTERIO DE TRABAJO Y PROMOCIÓN DEL EMPLEO PROGRAMA TRABAJA PERÚ

MINISTERIO DE TRABAJO Y PROMOCIÓN DEL EMPLEO PROGRAMA TRABAJA PERÚ MINISTERIO DE TRABAJO Y PROMOCIÓN DEL EMPLEO PROGRAMA TRABAJA PERÚ Documento de Estándares para el Proceso de Desarrollo de Software Documento de Estándares para el Proceso de Desarrollo de Software Página

Más detalles

Visión preliminar

<Generador de exámenes> Visión preliminar 1. Introducción Proyecto Final del curso Técnicas de Producción de Sistemas Visión preliminar Para la evaluación de algunos temas de las materias que se imparten en diferentes niveles,

Más detalles

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI)

UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) UNIVERSIDAD PARA LA COOPERACION INTERNACIONAL (UCI) PROPUESTA DE METODOLOGÍA Y ESTÁNDARES PARA LA ADMINISTRACIÓN DE PROYECTOS EN LAS PEQUEÑAS Y MEDIANAS EMPRESAS DE SOFTWARE CON BASE EN LOS ESTANDARES

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

Ciclo de vida del software

Ciclo de vida del software RUP para Mantenimiento de Software Preparado por: Amelia Soriano Ciclo de vida del software Análisis del problema Liberación del producto Comprensión del problema Desarrollo del software RUP Ciclo Típico

Más detalles

INGENIERÍA DE SOFTWARE ADMINISTRACION DE CONFIGURACIONES Rubby Casallas, Juan Pablo Quiroga, Andrés Yie

INGENIERÍA DE SOFTWARE ADMINISTRACION DE CONFIGURACIONES Rubby Casallas, Juan Pablo Quiroga, Andrés Yie INGENIERÍA DE SOFTWARE ADMINISTRACION DE CONFIGURACIONES Rubby Casallas, Juan Pablo Quiroga, Andrés Yie Departamento de Sistemas y Computación Facultad de Ingeniería Universidad de los Andes Agenda 2 Problema

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

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

Historia de revisiones

Historia de revisiones Proyecto Help-Desk Plan de Verificación y Validación Versión 1.0 Historia de revisiones Fecha Versión Descripción Autor 16/08/2005 1.0 Primera versión del documento Martín Boero Plan de Verificación y

Más detalles

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Gestión de Configuración de Software: Requisitos para la resolución de la práctica El alumno debe haber asistido a la clase de Gestión de Configuración y de Gestión de Requerimientos.

Más detalles

GUÍA AVANZADA DE GESTIÓN DE CONFIGURACIÓN LNCS

GUÍA AVANZADA DE GESTIÓN DE CONFIGURACIÓN LNCS GUÍA AVANZADA DE GESTIÓN DE CONFIGURACIÓN LNCS Diciembre 2008 AVISO LEGAL CMMI es una marca registrada en la Oficina de Marcas y Patentes de EEUU por la Universidad Carnegie Mellon Las distintas normas

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

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

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

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

Crear un Proyecto en Rational RequisitePro.

Crear un Proyecto en Rational RequisitePro. Crear un Proyecto en Rational RequisitePro. 1. Seleccione el botón Inicio, luego Programas, Rational RequisitePro, entonces seleccione Rational RequisitePro 2. Desde RequisitePro, haga click en Archivo

Más detalles

UNIVERSIDAD TÉCNICA DEL NORTE

UNIVERSIDAD TÉCNICA DEL NORTE UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN SISTEMAS COMPUTACIONALES

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

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

P R U E B A S D E S O F T W A R E 1 Pruebas de Software

P R U E B A S D E S O F T W A R E 1 Pruebas de Software PRUEBAS DE SOFTW ARE 1 Pruebas de Software 2 PRUEBAS DE SOFTWARE 3 ÍNDICE Página Presentación 5 Red de contenidos 6 Unidad de aprendizaje 1: Fundamentos de Pruebas de Software 1.1 Tema 1 : Pruebas de Software

Más detalles

Desarrollo ágil en tiempos de crisis. Alejandro Torres Castañeda y Analía Baño Dynkowski Baufest

Desarrollo ágil en tiempos de crisis. Alejandro Torres Castañeda y Analía Baño Dynkowski Baufest Desarrollo ágil en tiempos de crisis Alejandro Torres Castañeda y Analía Baño Dynkowski Baufest allaboutagile.com It is not the strongest of the species that will survive or the most intelligent. It is

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

Consideraciones para implementaciones BPM y EDA

Consideraciones para implementaciones BPM y EDA Consideraciones para implementaciones BPM y EDA Jesús Buriticá IBM Software Group Brand Architect jburitic@ve.ibm.com Agenda Manejando los conceptos sobre BPM y EDA Abordar una iniciativa BPM/EDA Algunos

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

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1

Sinopsis de la gestión de programas de acuerdo con el estándar del Project Management Institute 1 Sinopsis de la gestión de s de acuerdo con el estándar del Project Management Institute Conceptos básicos Qué es un? Es un grupo de proyectos gestionados de modo coordinado para obtener beneficios y el

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

Tema 2. El Ciclo de Vida del Software (ISG1-ITIG)

Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Tema 2. El Ciclo de Vida del Software (ISG1-ITIG) Grupo de Ingeniería del Software Antonio José Sáenz Albanés (C.T.O) Reconocimiento No Comercial Compartir Igual - 3.0 - España 1 Objetivos del Tema Qué

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

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

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 Rational Unified Process RUP

INGENIERÍA DE SOFTWARE Rational Unified Process RUP 1 INGENIERÍA DE SOFTWARE Rational Unified Process RUP Rubby Casallas Departamento de Sistemas y Computación Facultad de Ingeniería Universidad de los Andes Referencias 2 http://www.rational.com/ http://www-306.ibm.com/software/awdtools/rup/

Más detalles

Guía metodologíca para la gestión de proyectos de software basada en metodologías agiles, que integre las herramientas de seguimiento de actividades,

Guía metodologíca para la gestión de proyectos de software basada en metodologías agiles, que integre las herramientas de seguimiento de actividades, Guía metodologíca para la gestión de proyectos de software basada en metodologías agiles, que integre las herramientas de seguimiento de actividades, integración continua y repositorio distribuido de versiones.

Más detalles