1 / 54

GESTION DE CONFIGURACION DE SOTFWARE

GESTION DE CONFIGURACION DE SOTFWARE. 1. INTRODUCCION. La gestión de la configuración del software es uno de los procesos clave para toda organización dedicada a la Ingeniería del Software. 2. DEFINICIONES. GESTION DE CONFIGURACION DE SW (GCS): - Conjunto de actividades [ Pressman ]

tino
Download Presentation

GESTION DE CONFIGURACION DE SOTFWARE

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. GESTION DE CONFIGURACION DE SOTFWARE

  2. 1. INTRODUCCION • La gestión de la configuración del software es uno de los procesos clave para toda organización dedicada a la Ingeniería del Software

  3. 2. DEFINICIONES • GESTION DE CONFIGURACION DE SW (GCS): - Conjunto de actividades [Pressman] • Proceso de identificación y definición [IEEE] • Arte [BAB] • Procesos de soporte [Lic. Aylin Febles ]

  4. 2. DEFINICIONES • CONFIGURACION DE SOTFWARE (CS): Los requisitos, diseño e implementación que definen una versión particular de un sistema o de un componente del sistema. [IEEE, 1990].

  5. 2. DEFINICIONES • ADMINISTRACION DE CONFIGURACION DE SOFTWARE Disciplina de la Ingeniería de Software que comprende las herramientas y técnicas. Tiene como objetivo mantener la integridad de los componentes del producto de software, evaluar y controlar los cambios

  6. 3. CALIDAD DEL SW La administración de la calidad total (TQM) es un estilo de administración dirigido a lograr éxitos a largo plazo enlazando la calidad con la satisfacción del cliente.

  7. 4. LINEAS BASE Evolución de las líneas Base:

  8. 4. LINEAS BASE La IEEE define una línea base como: Una especificación o producto que se ha revisado formalmente y sobre los que se ha llegado a un acuerdo, y que de ahí en adelante sirve como base para un desarrollo posterior y que puede cambiarse solamente a través de procedimientos formales de control de cambios.

  9. INGENIERIA DE SISTEMAS Especificación del sistema Ciclo de vida Tradicional: ANÁLISIS DE REQUERIMIENTOS Especificación de requisitos del software DISEÑO DEL SOFTWARE Especificación de diseño CODIFICACIÓN Código fuente PRUEBA Planes de prueba Sistema en funcionamiento

  10. ANÁLISIS PRELIMINAR Y ESPECIFICACIÓN DE REQUISITOS Refinamiento evolutivo Requisitos Iniciales Ciclo de Vida Prototipado Evolutivo REFINAMIENTO DE ESPECIFICACIONES DISEÑO RÁPIDO Diseño inicial Rediseño evolutivo CONSTRUCCIÓN IMPLEMENTACIÓN Y PRUEBA EVALUACIÓN DEL PROTOTIPO Construcción Construcción evolutiva PRODUCTO DE INGENIERÍA IMPLANTACIÓN DEL SISTEMA Producto Final MANTENIMIENTO

  11. EVALUACIÓN DE ALTERNATIVAS IDENTIFICACIÓN Y RESOLUCION DE RIESGOS DETERMINACIÓN DE OBJETIVOS, ALTERNATIVAS Y RESTRICCIONES Ciclo de vida en espiral: 3 2 1 IMPLEMENTACION DEL SOTFWARE 4 PLANIFICACIÓN Ingenieria Producto Final Mantenimiento 1 Líneas Base inicial 2 Lineas Base de Refinamiento 3 Lineas Base de Diseño 4 Lineas Base de Implementacion

  12. 5. ELEMENTOS DE LA CONFIGURACION DE SW • 1) Especificación del sistema • 2) Plan de proyecto • 3) Especificación de requisitos, Prototipo ejecutable o “en papel” • 4) Manual de usuario preliminar • 5) Especificación de diseños • 6) Listados del código fuente

  13. 5. ELEMENTOS DE LA CONFIGURACION DE SW • 7) Plan y procedimiento de pruebas, Casos de prueba y resultados registrados • 8) Manuales de operación de y de instalación • 9) Programas ejecutables • 10) Descripción de la base de datos • 11) Manual del usuario final • 12) Documentos de mantenimiento • 13) Estándares y procedimientos de ingeniería del software

  14. 6. GESTION DE CONFIGURACION DE SW Los cambios dentro del desarrollo del SW pueden ocurrir en cualquier momento por lo tanto debemos estar preparados, las actividades de CGS sirven para: • Identificar el cambio de nuestro software. • Controlar ese cambio. • Garantizar que el cambio quede bien implantado. • Informar el cambio.

  15. 6. GESTION DE CONFIGURACION DE SW PROBLEMAS DE ADOPCION DE LA GCS • No se encuentran la ultima versión del CF • Errores corregidos en anteriores versiones • No existe seguimiento de los requerimientos • Problemas importantes en la administración, etc.

  16. 6. GESTION DE CONFIGURACION DE SW QUE PERMITE CONOCER LA GCS • ¿Quién hizo los cambios? • ¿Qué cambios se hicieron al software? • ¿Cuándo se hicieron los cambios? • ¿Por qué se hicieron los cambios?

  17. 6. GESTION DE CONFIGURACION DE SW La GCS es una actividad de garantía de calidad del software que se aplica en todas las fases del proceso de ingeniería del software.

  18. 7. PROCESO DE GCS ISO Identificación de la configuración Control de cambios a la configuración Informe del estado de la Configuración Auditoria de la configuración IEEE Identificación de la Configuración Control de Cambios en la Configuración Generación de Informes de Estado Auditoria de la Configuración CMM Planificación de las actividades de Gestión de Configuración Identificación de los ECS Control de cambios a los ECS Informar a los grupos e individuos involucrados de los cambios a los ECS Auditoria de la Configuración CM (Configuration Magnament). Identificación Control Auditoria Contabilidad de Estado

  19. Proceso de Gestión de Configuración del Software

  20. 8. IDENTIFICACION DE LA CONFIGURACION Tarea de gestión de configuraciones del software referido a un esquema de identificación que proporciona la siguiente información: • Tipo de elementos de configuración de software (ECS) • Nombre del elemento de configuración • Identificación del proyecto o del producto. • Numero de versión • Fecha de ultimo lanzamiento

  21. OBJETIVO: Identificar la estructura del SW., META: Tener la capacidad de identificar los componentes del SW PREGUNTAS: ¡Cual es la configuración del SW? ¡Que versión de archivo es esta? ¡Cuales son los componentes del SW? 8. IDENTIFICACION DE LA CONFIGURACION

  22. Establecer la estructura jerárquica del SW • Crear e identificar el esquema de la estructura anterior Identificar unívocamente cada uno de los componentes del producto Definir las relaciones e interfaces entre los productos de SW Seleccionar los elementos que estarán bajo control de configuración Pasos a seguir:

  23. IDENTIFICACIÓN DE OBJETOS EN LA CONFIGURACIÓN DEL SW • OBJETOS BASICOS: Es una unidad de texto creada durante el análisis, diseño, codificación o prueba. • OBJETOS COMPUESTOS: Es una colección de objetos básicos u objetos compuestos.

  24. Revisión Variante VERSIONES SOFTWARE De producto Funcional Asignada De desarrollo CONFIGURACIÓN DE REFERENCIA (BASELINE) Forma parte de la gestión de configuraciones Seguridad BIBLIOTECA SOFTWARE software [IEEE 610] IDENTIFICACIÓN DE OBJETOS EN LA CONFIGURACIÓN DEL SW

  25. 9. CONTROL DE CONFIGURACION • CONTROL DE VERSIONES El control de versiones combina procedimientos y herramientas para gestionar las versiones de los objetos de configuración creadas durante el proceso de ingeniería del software.

  26. Versiones y variantes

  27. PROCESOS PARA EL DESARROLLO DE SW POR VERSIONES • Rational Unified Process (RUP) • Modelo Java (2000 – 2003) • Modelo Java (2000 – 2003) cont • Modelo GXP (2003) • Modelo Java Integrado (2003) • Modelo TLREQ (2004)

  28. Cubre todo el ciclo de vida de los Proyectos, maximizando el uso del UML proceso de ingeniería de software Esta dirigido por casos de uso, centrado en la arquitectura e iterativo e incremental Desarrollo en cuatro fases: Transición Inicial Elaboración Construcción Rational Unified Process (RUP) RUP

  29. Requerimientos • Análisis • Diseño • Implementación • Verificación Líneas de Trabajo (o disciplinas) definidas (JAVA CONT) adaptaciones (JAVA CONT) Roles Soporte Gestión de Proyecto Gestión de Configuración Gestión de Calidad Modelo Java (2000 - 2003) JAVA

  30. Adaptaciones similares a las del Modelo Java Desarrollo con Genexus Actividades Roles específicos Modelo MoDSGX (2002 - 2003) MoDSGX

  31. Adaptación de eXtreme Programming (XP) Desarrollo con Genexus Modelo GXP (2003) GXP

  32. Módulo agregado al Modelo Java Roles específicos Actividades Modelo Java Integrado (2003) • JAVA INTEGRADO

  33. Java MoDSGX Esqueleto común basado en el RUP Redundancia Duración del proyecto FIJO Modelo TLREQ (2004) TLREQ

  34. CONTROL DE CAMBIOS Para un gran esfuerzo de desarrollo de SW el cambio incontrolado lleva rápidamente al caos. El control de cambios de la tarea de Gestión de Configuración de Software (GCS) mas importante proporciona un mecanismo para el control de los cambios.

  35. NECESIDAD DE CAMBIO EVALUACIÓN GENERACIÓN DE INFORME DE CAMBIOS GENERACIÓN DE PETICIÓN DE CAMBIO INFORMAR AL CLIENTE DECISIÓN ACC SITUAR EN COLA DE CAMBIOS OTRAS TAREAS DEGCS

  36. CONTROL DE CAMBIOS • OBJETIVO Controlar los cambios y la liberación de los productos durante el ciclo de vida. • META Establecer un mecanismo que asegure la producción del SW de calidad.

  37. PREGUNTAS: ¡Que esta controlado? ¡Como son controlados los cambios a los productos? ¡Quien controla los cambios? CONTROL DE CAMBIOS

  38. Establecer las políticas y procedimientos de control de cambios Mantenimiento de las líneas Base Incorporar los cambios Desarrollar la forma de reportes de cambio Controlar la liberación del producto Definir el proceso de cambio Pasos a seguir:

  39. 10. AUDITORIA DE LA CONFIGURACION ¿Cómo podemos asegurar que el cambio se ha implementado correctamente? 1) Revisiones técnicas formales : se centran en la corrección técnica del elemento de configuración que ha sido modificado. 2) Auditorias de configuración del software: complementa la revisión técnica formal

  40. 10. AUDITORIA DE LA CONFIGURACION • OBJETIVO Verificar que el producto de SW integrado satisface los requerimientos estándares o acuerdos contractuales y que los componentes que se integran corresponden con las versiones vigentes. • META Verificar que todos los productos de SW han sido producidos descritos e identificados correctamente y que todas las solicitudes de cambio han sido procesadas.

  41. 10. AUDITORIA DE CONFIGURACION La auditoria se plantea las siguientes interrogantes: • ¡Se ha hecho el cambio especificado en la (OCI)? • ¡Se han incorporado modificaciones adicionales? • ¡Se ha llevado acabo una revisión técnica formal para comprobar la corrección técnica? • ¡Se han seguido adecuadamente estándares de ingeniería de SW? • ¡Se han remarcado los cambios en el ECS? • ¡Se han especificado la fecha del cambio y el autor del cambio? • ¡Refleja la identificación del ECS los cambios? • ¡Se han seguido procedimientos del GCS para señalar el cambio, registrarlo y divulgarlo? • ¡Se han actualizado adecuadamente todos los ECS relacionados?

  42. 11. CONTABILIDAD DE ESTADO Denominada también informes de Estado; es una tarea de la gestión de configuración de SW: • ¡Que paso? • ¡Quien lo hizo? • ¡Cuando paso? • ¡Que mas se vio afectado?

  43. IDENTIFICACIÓN DE BONIFICACIÓN GENERACIÓN DE INFORMES DE ESTADO CONTROL DE CONFIGURACIÓN INFORME IEC AUDITORIA DE CONFIGURACIÓN 11. CONTABILIDAD DE ESTADO Flujo de información del proceso de generación de informes de estado de configuración (GIEC). ECS BASE DE DATOS DE ICE CAMBIOS

  44. 11. CONTABILIDAD DE ESTADO OBJETIVO Registrar y reportar los cambios a los componentes de configuración. META Mantener un registro del estado de todos los elementos en una línea base. • ¡Que cambios se han hecho al sistema? • ¡Cuantos componentes fueron afectados por estos cambios?

  45. Dar seguimiento al estado de los componentes de configuración Dar seguimiento al estado de cambios al sistema Generar reportes de estado Registrar y reportar las actividades de SCM Determinar el tipo de reporte requerido Pasos a seguir:

  46. 12. MODELOS Y ESTANDARES • MODELO DE MADUREZ DE CAPACIDADES (CMM) Describe un marco de referencia para el desarrollo y mantenimiento de software Constituye un modelo en el que el mejoramiento de los procesos es implementado de forma incremental. Organiza las etapas para evolucionar los procesos de software en cinco niveles: inicial, definido, repetible, gestionado y optimizado [Dunaway, 1996] [Farley, 2000] [Cruz, 2002]

  47. 12. MODELOS Y ESTANDARES • LA ORGANIZACIÓN INTERNACIONAL PARA LA ESTANDARIZACIÓN (ISO) Promueve la estandarización internacional. En relación al software, existe la guía o reglas generales ISO 9000-3. es una guía y no una norma. La ISO 9000 del 2000 identifica ocho principios de gestión de la calidad: * Enfoque al cliente * Liderazgo * Participación del personal * Enfoque basado en procesos * Enfoque de sistema para la gestión * Mejora continua * Enfoque basado en hechos para la toma de decisión * Relaciones mutuamente beneficiosas con el proveedor.

  48. 12. MODELOS Y ESTANDARES • INSTITUTO DE INGENIEROS ELÉCTRICOS Y ELECTRÓNICOS (IEEE) IEEE 730, este estándar permitió identificar los aspectos más importantes para la realización del plan de aseguramiento de la calidad Entre lo documentos normativos: * IEEE Guide to Software Configuration Management, American National Standards Institute, (1042-1987) * IEEE Standard for Software Configuration Management Plans, American National Standards Institute (828-1990).

  49. 12. MODELOS Y ESTANDARES • LA VINCULACIÓN DE ESTÁNDARES Existe una estrecha relación en todos estos modelos. CMM pueden cumplir con las exigencias de las certificaciones de ISO. Los aspectos con los que cumplen en ambos niveles podría resultar suficiente para certificarse como ISO .Entonces pudiera haber organizaciones no maduras (CMM) o por debajo del nivel 3 que obtuvieran la certificación ISO. De manera general, si una organización se considera posible candidata a ISO, es probable que esté cerca de alcanzar el nivel 2. Las que están en el nivel 3 con completa seguridad serán certificadas ISO9001. [Zhang, 2001]

  50. Vinculación de ISO y CMM

More Related