CM colabora con el proceso a través de la implementación de políticas de tracking, seguridad, integración y administración de cambios.

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

Download "CM colabora con el proceso a través de la implementación de políticas de tracking, seguridad, integración y administración de cambios."

Transcripción

1 1

2 Administración de Configuraciones - Introducción La facilidad de cambio en el software pone en riesgo la integridad de los productos. Cambios sin control, despliegue de componentes inconsistentes entre sí, o la falta de disponibilidad del componente adecuado en una determinada etapa del ciclo de vida, pueden desestabilizar la calidad de mi aplicación. Es de la sensibilidad al cambio presente en la disciplina de ingeniería de software que se desprenden las radicales diferencias que tiene esta actividad de la ingeniería con otras actividades de la industria. El dinamismo intrínseco del software genera la necesidad de contar con un framework para el control de cambios y estados de la configuración, es desde esta necesidad que surge CM (Configuration Management). Paradójicamente, la naturaleza sensitiva al cambio presente en el software hace que la burocracia enloscontrolesdecambioseaalgopositivodentrodeestecontexto. CM colabora con el proceso a través de la implementación de políticas de tracking, seguridad, integración y administración de cambios. 2

3 Entropía vs Actividad de Cambio La entropía aumenta en el software en forma continua a menos que acciones de control sean aplicadas sobre los cambios. Los casos patológicos de ejemplo son los legacy systems donde existen, en algunos casos, décadas de cambios sin documentar por lo que debe interpretarse las reglas del negocio a través de ingeniería inversa sobre el código. 3

4 Misión de CM (Configuration Management) La misión de la Administración de Configuraciones es custodiar la integridad de los productos a medida que evolucionan desde la especificación, pasando a través del diseño, el desarrollo, el despliegue a producción y el posterior mantenimiento. Su existencia tiene sentido como actividad de soporte que acompaña a los productos en la actividad de cambio a lo largo del ciclo de vida. El valor invertido en CM está relacionado con el costo del producto vs la exposición al riesgo de obtener un producto inestable. Entonces, cuál es el equilibrio entre el gasto en CM y exposición a dicho riesgo?, cómo mido dicho riesgo? 4

5 Software Configuration Management - Introducción Según el SEI, nos centramos en actividades específicas de SCM que, de ser cumplimentadas, pueden al menos garantizar ciertos niveles de calidad en la configuración. Nuestro enfoque partirá de observar a SCM también como un proceso, o sea que nos centraremos en sus actividades como propone el SEI. 5

6 Cambio - Incrementando la complejidad del Software Con este tipo de cambio nos referimos a modificaciones que sufre directamente el producto de software en sí sin incluir consideraciones del entorno. - Size Líneas de código Nuevos Módulos (Cambio de arquitectura) - Inclusión de componentes de terceras partes Controlar versiones de componentes por terceras partes. Grabar versiones que conforman el baseline del sistema de software - Incrementando el número de plataformas sobre las cuales el sistema opera La organización de test se ve afectada. SCM tool debería ejecutarse en todas las plataformas que el producto core 6

7 Cambio - Incrementando la complejidad del Entorno - Team Size Incrementar el tamaño del team significa aumentar la cantidad de líneas de comunicación. Por Ejemplo: 2 personas = 1 línea 3 personas = 3 líneas n personas = n* (n-1)/2 Acceso concurrente a los componentes aumenta. Complejidad en el merge de los cambios en paralelo. - Distribución geográfica del team Comunicación más compleja. Merge integration se hace imposible sobre los niveles superiores de integración. - Frecuencia de los Releases o cantidad de variantes Aumenta la cantidad de releases mantenidos al mismo tiempo. Los bug fixes son mas difíciles de distribuir. Los arreglos sobre versiones existentes colisionan con mayor número de versiones funcionando. - Cambio en plataformas de SO y Hardware Muchas veces no atendido, las partes de la configuración que no son software (como firmware y hardware) no son tenidas en cuenta como parte de la configuración con la consecuente desatención durante el mantenimiento. El SO, el hardware sobre el cual este funciona, como así también la versión de Firmware instalada en el Hardware son elementos de terceros que deben sr mantenidos bajo control de configuración. 7

8 Cambio - Cambiando el ciclo de vida El ciclo de vida determina dos aspectos que influyen sobre el plan de SCM: cantidad de versiones que deberé administrar y etapas durante las cuales aceptaré sean efectuados cambios sobre el producto en sí. La rigidez de los controles será directamente proporcional al avance del proyecto en la fase. A medida que me acerco al final de la fase, debo estar acercándome a tener algún entregable listo (versión). Esto hace que las restricciones para modificar el software sean incrementadas para asegurar que no existan desvíos, solo los cambios de urgencia o muy bien justificados tendrán lugar en esta etapa. De la misma manera, en ciclos de vida con un alto grado de prototipación, se hará énfasis en la auditoría en lugar de restringir que el team pueda modificar el producto. 8

9 Definiciones: Artifact: Cualquier elemento de un producto de software que esté sujeto a cambios. Esto incluye código fuente, documentación, planes de prueba, datos de prueba, librerías, código objeto, etc. Tambiénesconocidoenlaterminologíatraducidaqueencontramoscomo ítemdeconfiguración. Baseline: Todo artifact seencuentrasujetoaunapolíticade versionado. Un producto de software está compuesto por un conjunto de artifacts cada uno de los cuales pertenezca a una versión específica. La idea de baseline entonces es establecer qué versión de cada artifact corresponde a cada versión producto de software. El baseline no contendrá ningún producto sino que será simplemente un conjunto de pares <artifact, version number> que servirá para determinar que ítems de configuración debe seleccionar la herramienta SCM para poder reproducir una versión determinada de mi producto. Variante: Una instancia del sistema que es funcionalmente idéntica pero que a nivel no funcional distinta de las otras instancias del sistema. Un ejemplo de esto es tener una variante distinta para cada plataforma de software y hardware. Cambios en el look and view del producto son otros motivos para generar nuevas variantes. Versión: Una instancia del sistema funcionalmente distinta de las otras instancias del mismo sistema. Release: Una instancia del sistema que es distribuida a los usuarios fuera del equipo de desarrollo. 9

10 Entorno CM Products Los productos sujetos a control de configuracion son todos aquellos que, al ser afectados por un cambio, pudieran afectar la integridad de la aplicacion. Implementation Processes La necesidad de operar sobre diversos ambientes nos obliga a conservar, al menos, entornos de produccion y desarrollo por separado. La actividad de cambio en ambos entornos tendra diferente volatilidad y por ende, debera poder ser aislada. CM Processes La integridad de los productos a lo largo de los entornos es gestionada a partir de las practicas de CM que se describen a lo largo de este presentacion. 10

11 Actividades Esenciales Nos centramos en actividades específicas, estas actividades son dependientes de la configuración SCM, la cual es a su vez dependiente del tipo de industria sobre la cual se está aplicando. Si bien estas actividades son varias, hemos extraído 10 de ellas que consideramos esenciales desde el punto en que todas ellas son imprescindibles sin importar el tipo de desarrollo en el cual nos encontremos involucrados. Identificar y almacenar artifacts en un repositorio seguro El primer paso para realizar SCM es identificar los artifacts que deberán ser mantenidos bajo control de versiones. Tanto los utilizados para administrar y diseñar el sistema (plan de proyecto, documento de diseño, etc.) como aquellos requeridos para construir la aplicación (código fuente, código objeto, librerías, archivos de ayuda, etc.) deben ser mantenidos bajo control de las actividades de SCM. Cualquier persona que haya trabajado en construcción de software conoce la dificultad que existe en encontrar la versión corecta del archivo corecto cuando las versiones no son almacenadas en forma ordenada. De aquí la utilidad del concepto de baseline visto anteriormente. Sin embargo, la localización y almacenamiento no son suficientes. Dado que el repositorio es potencialmente un centro de falla, debemos pedir que además sea robusto y tolerante a fallas. Escalabilidad, replicación, y distribución son atributos adicionales para la administración de proyectos de cierta envergadura. Desde este último punto de vista, la herramienta SCM operará como una base de datos que, dependiendo del scope de acceso (puntos geográficos diferentes), tamaño de la organización, etc., escalará tal cual lo hace un DBMS. 11

12 Actividades Esenciales Controlar y auditar cambios sobre los artifacts. Una vez que los artifacts son identificados y almacenados en el repositorio, debe ser posible definir quién puede modificarlos como así también quién ha modificado un artifact. Cuando ha ocurrido esto, por qué ha sido modificado y qué ha sido modificado. A este tipo de información la denominamos información de auditoría. La IEEE la denomina configuration control y configuration status accounting respectivamente de la siguiente forma: laevaluación,cordinación,aprobaciónodesaprobación,eimplementacióndecambios sobreítemsdeconfiguración y, elregistroyemisióndereportesdelainformaciónrequeridaparaadministrarla configuracióneficientemente. 12

13 Actividades Esenciales Controlar y auditar cambios sobre los artifacts. Idealmente, dado que estas restricciones deben tener un impacto mínimo sobre la productividad, los controles deben ser dinámicos y acompañar la fase en la que encuentre la versión sobre la cual me encuentro operando. Sobre el inicio de una nueva fase, debemos poder modificar un determinado artifact sin contar con demasiados controles. A medida que me voy acercando a la etapa de entrega, debopoderrestringirloscambioscadavezmashastaalcanzarlaetapade congelamiento durante la cual ya no posible realizar cambios hasta se haga la liberación del release. Notar que a menor rigidez en el control de cambios mayor actividad de auditoría. 13

14 Actividades Esenciales Organizar artifacts en forma de componentes versionados. Una vez que tengo mas que unos cientos de archivos y directorios en el sistema, comienza a ser necesario agrupar estos archivos con una menor granularidad para hacer posible su administración. Nos referimos a SCM components como al conjunto de archivos y directorios relacionados queson versionados,compartidos,vinculadoseidentificadoscomounaunidad. Dado que la estructura de la configuración es intrínseca a la aplicación y no a su administración de configuración, es que requerimos un nivel diferente de agrupamiento para administrar la seguridad, auditoría y versionado. De esta necesidad administrativa es que surge el concepto de component cuya utilidad es de administración de versiones, seguridad y auditoría. 14

15 Actividades Esenciales Organizar artifacts en forma de componentes versionados. Ventajas Mapeando componentes lógicos de diseño a SCM components físicos contribuye a preservar la integridad de la arquitectura del sistema Los componentes no pueden tener una cohesión coincidental, los mismos deben ser agrupados de acuerdo a los criterios utilizados durante el diseño. SCM Components reducen la complejidad Agrega un nivel adicional de abstracción por encima de los archivos y directorios físicos. Es más fácil identificar el nivel de calidad de una determinada versión de un componente que de un conjunto numeroso de archivos individuales Dado que un componente contiene un conjunto consistente de versiones de archivos y directorios, puede ser probado como una unidad. El hecho de administrar los archivos en forma atómica a través del uso de componentes contribuye a institucionalizar el reuso y compartición de los componentes Facilita el acceso a la versión correcta del archivo correcto al reducir el espacio de búsqueda. 15

16 Actividades Esenciales Crear baselines para cada milestone del proyecto. Todos los componentes y artifacts que conforman un sistema de software, deben ser agrupados seleccionando la versión correcta para cada uno de ellos bajo una línea de base (baseline). Cada etapa del schedule del proyecto donde se presenta un milestone, debemos tener un entregable auditable y reproducible. Al menos debe ser creado un baseline al final de cada iteración del proyecto. Típicamente, nuevos baselines son creados con mas frecuencia a medida que nos acercamos al final de una iteración o también, a la etapa de entrega. Esto nos habilita a reproducir cualquier versión de mi sistema de software, consultar qué cambios han sido realizados, e indicar la estabilidad de la versión utilizando los atributos almacenados en la línea de base. Nota: La mayor cantidad de baselines no se debe a una mayor actividad de cambio sino a que se hace necesario poder volver a un release mas reciente. 16

17 Actividades Esenciales Crear baselines para cada milestone del proyecto. Motivación Existen tres razones principales para realizar un baseline: 1. Reproducibility Es la habilidad de poder ir hacia atrás y re-generar cualquier release o entorno del sistema que haya sido liberado antes. Esto es indispensable para identificar problemas nuevos generados por nuevos releases. 2. Traceability Es la posibilidad de unir requerimientos, planes de proyecto, casos de prueba, y artifacts todos juntos de modo de no solo poseer el release concerniente al sistema de software sino también, la información técnica requerida para comprender dicho sistema. 3. Reporting Es la habilidad de poder consultar el contenido de cualquier baseline y poder además comparar un baseline con otro. La comparación de baselines nos asiste durante la etapa de debugging y la generación de notas de release. La comparación de baselines es utilizada en la actividad de Perreviews Estas tres propiedades nos ayudan a corregir errores en productos liberados y facilita auditorías.. 17

18 18

19 19

20 Actividades Esenciales Registrar y hacer seguimiento a change requests. Change Request Management involucra seguimiento de los requerimientos de cambio sobre un sistema de software. Estos pueden provenir de requerimientos de mejora (enhancements) o corrección de errores (defects). Nota: Este punto es tratado más adelante en mayor profundidad. 20

21 Actividades Esenciales Registrar y hacer seguimiento a change requests. La relación entre SCM y SRM (Software Requirement Management) es muy cercana, de hecho actividades de gestión de requerimientos eficientes tienden a mejorar la gestión de cambios en el software. Cada requerimiento del cliente que ingresa desde el proceso de SRM, es traducido a una serie de requerimientos de cambio que se registra en un backlog (aquí change request backlog). La idea es que la gestión de ese backlog, sin perder trazabilidad sobre el pedido del cliente, está orientada a la estrategia de asignación de actividades a los equipos de desarrollo, y de las posibilidades de desarrollar diferentes cambios en forma concurrente. Muchas veces diferentes pedidos de cambios del cliente (ingresantes desde SRM), se traducen en cambios sobre los mismos componentes. Otras veces, la naturaleza de la configuración impide que podamos efectuar un cambio antes que otro o en forma concurrente. Estos casos dirigen de alguna manera la estrategia de cómo gestionaré el backlog, y por ende el orden en que serán resueltos los pedidos del cliente. La gestión de este backlog es fundamental desde el punto de vista de SCM ya que una actividad ordenada desde este lugar reduce las necesidades de merge integracion, disminuye los costos de pruebas integrales, y maximiza la cantidad de temas que pueden ser resueltos en cada actividad. 21

22 Actividades Esenciales Organizar e integrar conjuntos consistentes de versiones usando actividades. Mientras que SCM provee control de versiones a nivel de archivo, es dejado en manos del desarrollador el seguimiento sostenido de qué versión de qué archivo deben ir juntos con el objetivo de implementar un cambio lógico y consistente, y para asegurar que este cambio es integrado como una unidad. Muchas herramientas SCM colaboran con el desarrollador asistiéndolo en que requerimiento se está trabajando actualmente o qué error es el que está intentando corregir. El grupo de componentes y artifacts modificados conforman un change set que es tratado como una unidad en el momento de su implementación (conocido como pack en algunos entornos). El poder de unir las disciplinas de change request management, configuration management y project management en un change set, es desde donde se hace visible el poder de esta propuesta. Una actividad une un conjunto de change requests a un conjunto de recursos del equipo permitiendo de esta manera vincular el stakeholder (requestor) a la tarea solicitada y a los recursos que la están desarrollando. Esto nos permite vincular la información requerida para facilitar la tarea de management, code review, cost analysis, etc. CR SCM Resources + CR => Activities Defect CR + Description => QA Control and Defect Prevention Activities + Release => Change Set 22

23 Actividades Esenciales Organizar e integrar conjuntos consistentes de versiones usando actividades. Ventajas 1. Cambios consistentes producen menos problemas de integración y generación. 2. El trabajo basado en actividades es la forma natural en que las personas trabajan. Generalmente los desarrolladores piensan en qué función, requerimiento de mejora o corrección de error están trabajando, todos estos no son mas que tipos de actividades. Trabajando centrados en las actividades, los desarrolladores se mantienen fuera de la complejidad de la implementación 3. La vinculación con un change request es inmediata. Dado que cada CR es vinculado con cada Change Set en forma única, existe una relación directa en cuanto a que CR se implementa bajo un Change Set determinado. 4. La vinculación con el área de project management es también directa. El estado del cambio, quién lo está realizando y una estimación del costo son propiedades de la actividad misma siendo esta información esencial para el área de project management. 5. El uso de actividades facilita la revisión de código. Dado que contamos con la versión anterior de cada ítem de configuración, el conocer las diferencias entre la versión nueva y la inmediata anterior permite aprovechar mejor el esfuerzo durante la etapa de revisión de código. 23

24 Actividades Esenciales Mantener espacios de trabajo consistentes y estables.. Tanto el entorno como los valores de configuración deben formar parte del conjunto de ítems de configuración. Esto nos lleva a la conclusión que la herramienta de SCM debe compartir la plataforma sobre la cual el producto opera. Este se convierte en un aspecto fundamental en la administración de configuraciones: No es posible hacer SCM si la herramienta no se encuentra totalmente integrada con el producto. No debe existir el salto del development del producto hacia su ejecución si no queremos perder visibilidad. Un aspecto importante es el nivel de aislamiento requerido para el éxito de esta actividad, debe ser posible construir y almacenar componentes stub que simulen el entorno de ejecución para poder testear y enfocarme sobre mis componentes de interés. 24

25 Actividades Esenciales Soportar cambios concurrentes sobre los artifacts Idealmente quisiéramos tener una única persona modificando un ítem de configuración a la vez. Dado que esto es ineficiente y no práctico, la complejidad introducida por el desarrollo concurrente debe ser resuella también por la herramienta SCM. Los cambios realizados en paralelo deben poder ser integrados con la asistencia de la herramienta de SCM. La serialización de cambios propuesta por algunas herramientas SCM presenta algunos inconvenientes... 25

26 Actividades Esenciales Soportar cambios concurrentes sobre los artifacts Problemas Algunos cambios, como la resolución de errores, no son serializables. Para esto la herramienta debe brindar la posibilidad de realizar un merge de los cambios en forma automática, en caso de que sea posible interpretar la estructura de un ítem de configuración, o en forma manual facilitando el acceso a los elementos modificados. 26

27 Actividades Esenciales Soportar cambios concurrentes sobre los artifacts Solución La solución es crear una nueva versión en base al merge de los cambios aplicados sobre las versiones 2 y 3. 27

28 Actividades Esenciales Integrar en forma temprana y frecuente. Durante la integración se descubren problemas en las interfaces y malentendidos en el diseño. Cuanto antes de realice la integración, antes será posible descubrir estos errores, siendo obviamente reducido el impacto del problema. Si se hizo un buen trabajo en la actividad 7 (Mantener espacios de trabajo consistentes y estables), a lo mejor el nivel de aislamiento hace que la necesidad de integrar se vea reducida y como consecuencia se vea un impacto en esta actividad. Tip La integración no debe ser realizada por la necesidad particular de una parte del team sino que debe ser una actividad rutinaria destinada a mas un proceso de verificación que de prueba de un módulo en particular. 28

29 Actividades Esenciales Asegurar sea posible reproducir releases de software. Vimos anteriormente que los baselines me permitían conocer el estado de mi producto de software y el entorno de ejecución en una instancia determinada. Los releases están vinculados a un baseline determinado por lo cual, de poder obtener todas las versiones de artifacts de mi herramienta SCM, podré reproducir mi release. La mención a esta actividad está relacionada con la política de releasing seleccionada de modo que, la información histórica mantenida en la herramienta SCM, sea consistente con la antigüedad de versiones en el mercado para las cuales aún estoy brindando mantenimiento. 29

30 Actividades Esenciales Resumen de Actividades Esenciales. 30

31 Integración Integración es el proceso a través del cual, los cambios desarrollados en forma independiente son juntados para formar una pieza de software que pueda ser ejecutada y probada. El trabajo del integrador es tomar el trabajo del equipo de desarrollo construyendo una versión única del sistema o, dependiendo del nivel de integración, un conjunto de componentes de software. Los niveles de integración se determinarán por la estructura del equipo de trabajo. A medida que crece la estructura del equipo de trabajo, los niveles de integración requeridos crecen en igual medida. 31

32 Integración Tipos de Integración Merge Integration es concerniente a la resolución de cambios en paralelo que son realizados por diferentes miembros del equipo sobre artifacts en común. En algunos casos el merge puede ser realizado automáticamente a través de herramientas que comprenden la estructura interna de los componentes. En otros casos, el merge deberá ser realizado en forma manual. Bajo la opción de merge manual, es posible sea necesario agregar nuevos cambios al componente resultante de modo que el merge conserve la union de las propiedades de las versiones combinadas. Assembly Integration involucra los procesos tendientes a crear una pieza de software a partir de varias componentes que comparten la misma baseline. Esta actividad nunca abarca modificaciones sobre los componentes. Assembly Integration puede ser realizado en tiempo de construcción o de ejecución, esto quiere decir que los componentes pueden ser ensamblados creando una única pieza de software ejecutable o conformar un conjunto de componentes ejecutables que compartan un entorno de ejecución. 32

33 Integración Tipos de Integración Consistent Merge Turn-Taking: Los componentes son accedidos en forma exclusiva por una persona o equipo de trabajo. Esto solo es practicable en equipos de desarrollo pequeños. Split-Combine: El producto es dividido en componentes independientes que son asignados a grupos separados. La concurrencia en el desarrollo es alta pero se acceden diferentes piezas a luego ser ensambladas eliminando de esta forma la complejidad existente en cambios inconsistentes sobre la misma pieza de software. A posibilidad de aplicar este tipo de integración aumenta a medida que la granularidad del dieño es mayor. Copy-Merge:Elmismocomponentees copiado enespaciosaisladosymodificadoen forma paralela por diferentes desarrolladores en espacios de trabajo aislados. La copia original del componente debe ser utilizada finalmente por el integrador en la etapa de merging para conocer cuales son los cambios realizados por cada uno de los desarrolladores. Las herramientas que colaboran en este tipo de merge utilizan la estructura del código fuente para poder aumentar el nivel lógico de aislación de los cambios. 33

34 Integración Categorías de Equipos de Desarrollo vs Integración Major Team Integration Existen dos niveles de integración en este caso. El primero es realizado por cada equipo de trabajo y es similar al realizado en el caso anterior. El siguiente nivel, junta los resultados de la integración efectuada por cada uno de los equipos del proyecto. La estructura del Team (orientada a arquitectura o a funcionalidad), determina el tipo de integración requerida en el segundo nivel. Si la orientación de la estructura es hacia arquitectura, el segundo nivel será un assembly integration. En otro caso, la integración será típicamente merge integration. Generalmente al primer nivel de integración se le llama subsystem o feature integration, mientras que al segundo nivel se le llama system integration. Extreme Team Integration Este tamaño de equipo de trabajo normalmente requiere mas de dos niveles de integración. Es importante evitar la construcción de aplicaciones monolíticas y construir equipos de trabajo cuya estructura permita el uso de assembly integration en los niveles superiores. En este tipo de teams, el tamaño y la complejidad de los sistemas desarrollados hace que la ventaja de la programación en paralelo se diluya en la complejidad del merge integration posterior. Incluso en el caso de poseer feature oriented teams, las funciones del sistema deberán ser divididas de modo que los subsistemas puedan ser modificados en forma aislada. El modo en el cual los sistemas son integrados y el número de niveles requeridos es determinado mayormente por la arquitectura del sistema. 34

35 Verapunte SCMPaterns defotocopiadora. Existencia de la línea principal (Mainline) Políticas sobre la línea de cambio activa (Active codeline). - Politicas de sincronizacion - Politicas de calidad. -- Commit a nivel de tarea (Task-level commit) Políticas sobre cambios sobre cada línea (Codeline policy). Línea de cambio de release (Release line) Preparación del release (Release-Prep Codeline) Rama a nivel de tarea (Task branch) 35

36 36

37 37

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Segundo Cuatrimestre 2008 Clase 20: Software Configuration Management Buenos Aires, 13 de Noviembre de 2008 Objetivos de la clase de hoy Ejemplos de la vida real Entender la problemática

Más detalles

Ingeniería de Software II

Ingeniería de Software II Ingeniería de Software II Primer Cuatrimestre de 2009 Clase 17 - Patrones y Líneas de Cambio en SCM Buenos Aires, 1 de Junio de 2009 Línea de Cambio y sus Componentes Definición: Un codeline es la progresión

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 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

Manejo de versiones 392

Manejo de versiones 392 Manejo de versiones 392 El desarrollo de software es un trabajo en equipo y cierto grado de confusión es inevitable. No puedo reproducir el error en esta versión! Qué pasó con el arreglo de la semana pasada?

Más detalles

Gestión de la configuración en el software (SCM) Ingeniería de software Eduardo Ferreira, Martín Solari

Gestión de la configuración en el software (SCM) Ingeniería de software Eduardo Ferreira, Martín Solari Gestión de la configuración en el software (SCM) Ingeniería de software Eduardo Ferreira, Martín Solari 1 Temario Definiciones Problemas del cambio Elementos de la configuración Actividades de SCM Identificación

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

Gestión de la Configuración (SCM) Introducción a la Ingeniería de Software

Gestión de la Configuración (SCM) Introducción a la Ingeniería de Software Gestión de la Configuración (SCM) Introducción a la Ingeniería de Software Temario Configuración del software Gestión de la Configuración Versiones Control de Cambios Línea base Auditoria de la configuración

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

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

Tema III: Gestión de la Configuración. Diana Marcela Sánchez Fúquene Ingeniería del Software de Gestión

Tema III: Gestión de la Configuración. Diana Marcela Sánchez Fúquene Ingeniería del Software de Gestión Tema III: Gestión de la Configuración. Diana Marcela Sánchez Fúquene Ingeniería del Software de Gestión Introducción Gestión de la Configuración del Software (GCS / SCM) Def.- Arte de identificar, organizar,

Más detalles

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS USB Ing. De Software. Prof. I. C. Martínez Ing. De Software Ingeniería de Software La Ingeniería de Software es la ciencia

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

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnología. Ingeniería de Software III Plan de Gestión de la Configuración

Universidad Católica del Uruguay. Facultad de Ingeniería y Tecnología. Ingeniería de Software III Plan de Gestión de la Configuración Universidad Católica del Uruguay Facultad de Ingeniería y Tecnología Ingeniería de Software III Plan de Gestión de la Configuración Cecilia Cedrés Braulio Zitto Versión: 1.0.0 Fecha: 11/11/2008 11/13/08

Más detalles

Mantenimiento del Software

Mantenimiento del Software Mantenimiento del Software S3 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

Control de Versiones con Subversion

Control de Versiones con Subversion Ingeniería del Software I Fa.M.A.F., Universidad Nacional de Córdoba 12 de agosto de 2009 Esquema de la charla El Proceso de Software El Proceso de Software Configuration Management Control de Versiones

Más detalles

IBM Rational Configuration Management V8.0.1 proporciona soluciones empresariales para la gestión de cambios y de configuración

IBM Rational Configuration Management V8.0.1 proporciona soluciones empresariales para la gestión de cambios y de configuración , con fecha 15 de octubre de 2013 IBM Rational Configuration Management V8.0.1 proporciona soluciones empresariales para la gestión de cambios y de configuración Índice 1 Visión general 2 Fecha de disponibilidad

Más detalles

Gestión de la Configuración del Software. Introducción. Elementos de la Configuración y Línea base. Objetivo

Gestión de la Configuración del Software. Introducción. Elementos de la Configuración y Línea base. Objetivo Gestión de la Configuración del Software Javier Tuya Universidad de Oviedo Departamento de Informática Introducción "Sin importar en qué momento del ciclo de vida nos encontremos, el sistema cambiará,

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

CMMi. Lic. Virginia Cuomo

CMMi. Lic. Virginia Cuomo CMMi Lic. Virginia Cuomo 1 Agenda Repaso CMMI Introducción Arquitectura Niveles de Madurez Representaciones Representación Discreta Representación Continua Discreta VS Continua 2 Repaso Qué vimos la tercer

Más detalles

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación

Liberando el sistema. Ayudar a los usuarios a entender y usar el sistema. Entrenamiento Documentación Solución de Problemas Conversión Instalación Liberando el sistema Ayudar a los usuarios a entender y usar el sistema Distintos tipos de usuarios Entrenamiento Documentación Solución de Problemas Conversión Instalación May-12 Ing. de Software Liberación

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

Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular.

Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular. El proceso software Un conjunto estructurado de actividades y resultados asociados que conducen a la creación de un producto de software Especificación: Definir la funcionalidad y las restricciones en

Más detalles

Evolución de Software

Evolución de Software Evolución de Software Marcello Visconti & Hernán Astudillo Departamento de Informática Universidad Técnica Federico Santa María Mantención de Software Gestión de Configuración

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

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

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

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

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

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

Modelo de Proceso de Desarrollo de Software

Modelo de Proceso de Desarrollo de Software Modelo de Proceso de Desarrollo de Software Documento de Actividades Gestión de Configuración (S.C.M.) Ingeniería de Software - Proyecto de Taller5 Andrea Delgado & Beatriz Pérez ÍNDICE ÍNDICE... 1 GESTIÓN

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 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

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

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

Más detalles

Jornadas de Introducción a la Ingeniería + Trabajo en Grupo = Herramientas de Gestion de Proyectos Software

Jornadas de Introducción a la Ingeniería + Trabajo en Grupo = Herramientas de Gestion de Proyectos Software Jornadas de Introducción a la Ingeniería + Trabajo en Grupo = Herramientas de Gestion de Proyectos Software Índice Conceptos básicos de gestión de proyectos software Gestión de grupos de trabajo Herramientas

Más detalles

Gestión de proyectos siguiendo practicas del PMI.

Gestión de proyectos siguiendo practicas del PMI. Gestión de proyectos siguiendo practicas del PMI. Identificación de las mejores prácticas aplicadas a la gestión de proyectos. Proceso de Desarrollo de Software de Codes S.A. alineado a CMMI Nivel 3 en

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

PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION)

PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION) PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION) INDICE 1. Introducción 2. Estructura CMMI 3. Nivel 2 4. Nivel 3 5. Nivel 4 6. Nivel 5 7. Bibliografía INTRODUCCIÓN Qué es y por qué usar CMMI?

Más detalles

CICLO DE VIDA DEL SOFTWARE

CICLO DE VIDA DEL SOFTWARE CICLO DE VIDA DEL SOFTWARE 1. Concepto de Ciclo de Vida 2. Procesos del Ciclo de Vida del Software 3. Modelo en cascada 4. Modelo incremental 5. Modelo en espiral 6. Prototipado 7. La reutilización en

Más detalles

Elementos requeridos para crearlos (ejemplo: el compilador)

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

Más detalles

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

SOFTWARE PROJECT MANAGEMENT PLAN

SOFTWARE PROJECT MANAGEMENT PLAN SOFTWARE PROJECT MANAGEMENT PLAN HERRAMIENTA PARA LA ADMINISTRACIÓN DE REQUERIMIENTOS DE LOS PROYECTOS DE LAS ASIGNATURAS DE INGENIERÍA Y ARQUITECTURA DE SOFTWARE DE LA PONTIFICIA UNIVERSIDAD JAVERIANA.

Más detalles

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de

2. EL MODELO CMMI. En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de 2. EL MODELO CMMI 2.1 ANTECEDENTES DE CMMI En 1991, el Instituto de Ingeniería de Software (SEI) publicó el Modelo de Capacidad de Madurez (CMM). Dicho modelo está orientado a la mejora de los procesos

Más detalles

Implantación de Sistemas

Implantación de Sistemas Implantación de Sistemas Maria Ines Parnisari 17 de Diciembre de 2014 Índice Parte 1: Implantación... 2 Factores clave para una implantación exitosa... 2 Etapas de un proyecto de Sistemas... 2 Fases de

Más detalles

Desarrollar el concepto del producto. Asignar requisitos de hardware y software. 1 1.1 1.2 2 2.1 2.2 3.. N

Desarrollar el concepto del producto. Asignar requisitos de hardware y software. 1 1.1 1.2 2 2.1 2.2 3.. N Fase de Análisis de Requerimientos Desarrollar el concepto del producto. Asignar requisitos de hardware y software. Realizar estudios de mercado. Sugerencia: www.anuies.mx para saber cuantas instituciones

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

Tema 12 Control de versiones

Tema 12 Control de versiones Bloque IV AUDITORÍA EN EL DESARROLLO DE SOFTWARE Tema 12 Control de versiones por José Francisco Vélez Serrano Tema 12 Control de versiones 1/23 Índice Índice Introducción Operaciones básicas Operaciones

Más detalles

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

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

Más detalles

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

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO.

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. 0. Consideraciones iniciales. Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón,

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

Itinerario. Conceptos Generales Quality Control Quality Assurance Más Sobre Calidad... Ingeniería de Software II Calidad 2

Itinerario. Conceptos Generales Quality Control Quality Assurance Más Sobre Calidad... Ingeniería de Software II Calidad 2 Calidad Itinerario Conceptos Generales Quality Control Quality Assurance Más Sobre Calidad... Ingeniería de Software II Calidad 2 Por qué hablamos de Calidad? Construir software es un proceso sujeto a

Más detalles

Iniciación y Planificación del Proyecto

Iniciación y Planificación del Proyecto Iniciación y Planificación del Proyecto Para cuando dijo que lo quería??? Ingeniería de Software 2 Iniciación y Planificación del Proyecto 1 Agenda Iniciación del Proyecto: Entradas Iniciación del Proyecto:

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

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 6. Actualización Página 1 de 19 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 6 Situación Contraste externo Actualización

Más detalles

Administración de Requerimientos

Administración de Requerimientos Administración de Requerimientos 1 Agenda Software Requirements Knowledge Areas. Requirement Statement. Requirement Specification. Agreement and Expectation Mgmt.. Las 5 dimensiones. Change Request Managment

Más detalles

MANUAL DE USUARIO Normativa para el desarrollo con Subversion de varias líneas paralelas (correctivo / evolutivo)

MANUAL DE USUARIO Normativa para el desarrollo con Subversion de varias líneas paralelas (correctivo / evolutivo) MANUAL DE USUARIO Normativa para el desarrollo con Subversion de varias líneas paralelas (correctivo / evolutivo) Versión 1.2 Área de Aplicaciones Especiales y Arquitectura de Software Hoja de Control

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

Cristian Blanco www.cristianblanco.es

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

Más detalles

Estándar para la Elaboración del Proceso Administración de Elementos de Configuración

Estándar para la Elaboración del Proceso Administración de Elementos de Configuración Seguridad del documento La clasificación de seguridad de la información de este documento, se ha establecido como bajo. Se ha creado y organizado con la expectativa de que esté a disposición de las unidades

Más detalles

Plan de estudios ISTQB: Nivel Fundamentos

Plan de estudios ISTQB: Nivel Fundamentos Plan de estudios ISTQB: Nivel Fundamentos Temario 1. INTRODUCCIÓN 2. FUNDAMENTOS DE PRUEBAS 3. PRUEBAS A TRAVÉS DEL CICLO DE VIDA DEL 4. TÉCNICAS ESTÁTICAS 5. TÉCNICAS DE DISEÑO DE PRUEBAS 6. GESTIÓN DE

Más detalles

Una prueba de concepto con Git Essentials. Introducción

Una prueba de concepto con Git Essentials. Introducción Miguel Ángel Hernández Miembro del Centro Experto Atlassian en atsistemas Introducción es una solución que proporciona a los jefes de equipo, jefes de proyecto, product owners y desarrolladores una mayor

Más detalles

Herramientas automáticas y semiautomáticas que apoyan a la aplicación de los métodos.

Herramientas automáticas y semiautomáticas que apoyan a la aplicación de los métodos. Unidad I Introducción a la ingeniería del software y sistemas de información Las economías de todos las paises son cada vez más y más dependientes del Software Importancia del Software 10 Cada vez más

Más detalles

Componentes de Integración entre Plataformas Información Detallada

Componentes de Integración entre Plataformas Información Detallada Componentes de Integración entre Plataformas Información Detallada Active Directory Integration Integración con el Directorio Activo Active Directory es el servicio de directorio para Windows 2000 Server.

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

Gestionando Agile/Scrum con Sciforma

Gestionando Agile/Scrum con Sciforma agile Gestionando Agile/Scrum con Sciforma El desarrollo ágil de software son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones

Más detalles

CICLO DE VIDA DEL SOFTWARE. Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software

CICLO DE VIDA DEL SOFTWARE. Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software 3.010 CONCEPTO DE CICLO DE VIDA Una aproximación lógica a la adquisición, el suministro, el desarrollo, la explotación y el mantenimiento del software IEEE 1074 Un marco de referencia que contiene los

Más detalles

SCL Artículos CONSULTING. Luis Aguado SCl Consulting CONSULTING

SCL Artículos CONSULTING. Luis Aguado SCl Consulting CONSULTING SCL Artículos Luis Aguado SCl Consulting Two value releases per year Este concepto es simple: la TI debe ser capaz de liberar 2 nuevas versiones (releases) para las soluciones de negocio al año, basadas

Más detalles

6.4 ESTRATEGIAS DE PRUEBA

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

Más detalles

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

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

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

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

Temario III Testing in the Large

Temario III Testing in the Large Temario III Testing in the Large 1ra Parte Verificación y Validación de Software UNS 1 Contenidos Testing de Integración Testing de Sistema Testing de Regresión Verificación y Validación de Software UNS

Más detalles

Uso practico de CVS para control de versiones

Uso practico de CVS para control de versiones Uso practico de CVS para control de versiones Conceptos y practicas recomendadas Franco M. Catrin L. Uso practico de CVS para control de versiones: Conceptos y practicas recomendadas por Franco M. Catrin

Más detalles

NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR

NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE IGNACIO BAYUGAR Ignacio.bayugar@mercadolibre.com, i id nachobayugar@gmail.com NUEVAS TENDENCIAS EN LA CALIDAD DEL SOFTWARE El desarrollo ágil El nuevo rol de

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

LISTA DE COMPROBACIÓN DE RIESGOS EN PROYECTOS SOFTWARE. Esta lista agrupa los riesgos de proyectos software en las siguientes categorías:

LISTA DE COMPROBACIÓN DE RIESGOS EN PROYECTOS SOFTWARE. Esta lista agrupa los riesgos de proyectos software en las siguientes categorías: LISTA DE COMPROBACIÓN DE RIESGOS EN PROYECTOS SOFTWARE Esta lista agrupa los riesgos de proyectos software en las siguientes categorías: A. Elaboración de la Planificación B. Organización y Gestión C.

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

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

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

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

Más detalles

2. Las funciones de control interno y auditoría informáticos.

2. Las funciones de control interno y auditoría informáticos. TEMA 9 AUDITORIA DE PROYECTO 1. Auditoría: Procedimiento reglado para analizar cualitativamente y cuantitativamente la eficiencia de un proceso, una tarea o un sistema. Las auditorias pueden ser internas

Más detalles

Servicio HP Software Support

Servicio HP Software Support HP Software Support s HP El HP Software Support brinda servicios de software completos para productos de software de HP y ciertos productos de terceros con soporte de HP. El HP Software Support suministra

Más detalles

Continuous Integration Contenido

Continuous Integration Contenido Continuous Integration Contenido Continuous Integration... 1 Principios del Manifiesto Ágil... 3 Concepto... 3 Qué es integrar?... 3 Qué implica construir?... 3 Entonces, Qué es la Integración Continua?...

Más detalles

MANTENIMIENTO DE SOFTWARE

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

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

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

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

Más detalles

Mantenimiento del Software

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

Más detalles

2.1 Ingeniería de Software

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

Más detalles

Visual Studio Team System 2010

Visual Studio Team System 2010 Visual Studio Team System 2010 5. Pruebas Automatizadas con Visual Studio 6. Pruebas codificadas de interfaz de usuario 7. Pruebas Web de desempeño Identificación de candidatos para la automatización Visual

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

Cómo las metodologías ágiles ayudan a los proyectos de Inteligencia de Negocios

Cómo las metodologías ágiles ayudan a los proyectos de Inteligencia de Negocios Cómo las metodologías ágiles ayudan a los proyectos de Inteligencia de Negocios Guillermo Watson Datalytics Stibenzon Cañas Sánchez Ceiba Software House Business Intelligence No es una tecnología ni un

Más detalles

IT Project Management Desarrollo de Software

IT Project Management Desarrollo de Software IT Project Management Desarrollo de Software Es posible una mezcla de Waterfall y Agile? Cómo se acerca el PMBOK a Agile? Autor: Norberto Figuerola Resulta muy frecuente que se suela confundir una aproximación

Más detalles

DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA

DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA Resumen AUTORIA CARLOS CABALLERO GONZÁLEZ TEMATICA INFORMÁTICA ETAPA ESO-BACHILLERATO-CFGM(ESI,ASI,DSI) Se describe la revolución que supuso la incursión

Más detalles

Servidores Donantonio

Servidores Donantonio Especificación de requisitos software Tabla de contenidos Juan José Amor David Escorial Ismael Olea 1. Introducción...3 1.1. Propósito...3 1.2. Ámbito del sistema...3 1.3. Definiciones, acrónimos y abreviaturas...3

Más detalles

Adquiera una mayor visibilidad y supervise la productividad de su equipo en tiempo real. Rational Team Concert Germán Domínguez

Adquiera una mayor visibilidad y supervise la productividad de su equipo en tiempo real. Rational Team Concert Germán Domínguez Adquiera una mayor visibilidad y supervise la productividad de su equipo en tiempo real. Rational Team Concert Germán Domínguez Agenda 1 El desafío de las empresas 2 Introducción a Rational Team Concert

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

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción

República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción República Bolivariana de Venezuela Ministerio Popular de Educación y Deportes UNEFA Cátedra: Base de Datos Unidad I. Introducción Dato: Hecho o valor a partir del cual se puede inferir una conclusión.

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles