Your SlideShare is downloading. ×
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Gestion de la configuracion del software
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Gestion de la configuracion del software

10,611

Published on

Published in: Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
10,611
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
366
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Las principales actividades de la  Gestión de Configuraciones  son: Planificación:  determinar los objetivos y estrategias de la  Gestión de Configuraciones . Clasificación y Registro:  los  CIs  deben ser registrados conforme al alcance, nivel de profundidad y nomenclatura predefinidos. Monitorización y Control:  monitorizar la  CMDB  para asegurar que todos los componentes autorizados estén correctamente registrados y se conoce su estado actual. Realización de auditorías:  para asegurar que la información registrada en la  CMDB  coincide con la configuración real de la estructura TI de la organización. Elaboración de informes:  para evaluar el rendimiento de la  Gestión de Configuraciones y aportar información de vital importancia a otras áreas de la infraestructura TI.
  • Los beneficios de una correcta  Gestión de Configuraciones  incluyen, entre otros: Resolución más rápida de los problemas , que redunda en una mayor calidad de servicio. Una fuente habitual de problemas es la incompatibilidad entre diferentes  CIs , drivers desactualizados, etc. La detección de estos errores sin una CMDB  actualizada alarga considerablemente el ciclo de vida de un problema. Una  Gestión de Cambios más eficiente . Es imprescindible conocer la estructura previa para diseñar un cambio que no genere nuevas incompatibilidades y/o problemas. Reducción de costes . El conocimiento detallado de todos los elementos de configuración permite, por ejemplo, eliminar duplicidades innecesarias. Control de licencias . Se pueden identificar tanto copias ilegales de software que pueden suponer tanto peligros para la infraestructura TI en forma de virus, etc. como incumplimientos de los requisitos legales que pueden repercutir negativamente en la organización. Mayores niveles de seguridad . Una  CMDB  actualizada permite, por ejemplo, detectar vulnerabilidades en la infraestructura. Mayor rapidez en la restauración del servicio . Si se conocen todos los elementos de configuración y sus interrelaciones será mucho más sencillo recuperar la configuración de producción en el tiempo más breve posible.
  • Las principales dificultades con las que topa la  Gestión de Configuraciones  son: Una incorrecta planificación : es esencial programar correctamente las actividades necesarias para evitar duplicaciones o incorrecciones. Estructura inadecuada de la CMDB : mantener actualizada una base de datos de configuraciones excesivamente detallada y completa puede ser una tarea engorrosa y que consuma demasiados recursos. Herramientas inadecuadas : es necesario disponer del software adecuado para agilizar los procesos de registro y sacar el máximo provecho de la  CMDB . Falta de Coordinación con la Gestión de Cambios y Versiones  que imposibilita el correcto mantenimiento de la  CMDB . Falta de organización : es importante que haya una correcta asignación de recursos y responsabilidades. Es preferible, cuando sea posible, que la  Gestión de Configuraciones  sea llevada a cabo por personal independiente y especializado. Falta de compromiso : los beneficios de la  Gestión de Configuraciones  no son inmediatos y son casi siempre indirectos, lo que puede provocar el desinterés de la gestión de la empresa y consecuentemente de los agentes implicados.
  • No siempre un cambio implica una  RFC . Para cambios de escasa importancia o que se repiten periódicamente pueden acordarse procedimientos estándar que no requiera la aprobación de la Gestión de Cambios  en cada caso. Independientemente de su origen el correcto registro inicial de una  RFC  requerirá, cuando menos, de los siguientes datos: Fecha de recepción. Identificador único de la  RFC . Identificador del error conocido asociado (dado el caso). Descripción del cambio propuesto: Motivación. Propósito. CIs  involucrados. Estimación de recursos necesarios para la implementación. Tiempo estimado. Estatus: que inicialmente será el de "registrado". ste registro deberá ser actualizado con toda la información generada durante el proceso para permitir un detallado seguimiento del mismo desde su aprobación hasta la evaluación final y cierre. La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos: Estatus actualizado: "aceptado", "rechazado", "implementado", ... Fecha de aceptación (denegación) del  RFC . Evaluación preliminar de la Gestión del Cambio. Prioridad y categoría. Planes de "back out". Recursos asignados. Fecha de implementación. Plan de implementación. Cronograma. Revisión post-implementación. Evaluación final. Fecha de cierre.
  • No siempre un cambio implica una  RFC . Para cambios de escasa importancia o que se repiten periódicamente pueden acordarse procedimientos estándar que no requiera la aprobación de la Gestión de Cambios  en cada caso. Independientemente de su origen el correcto registro inicial de una  RFC  requerirá, cuando menos, de los siguientes datos: Fecha de recepción. Identificador único de la  RFC . Identificador del error conocido asociado (dado el caso). Descripción del cambio propuesto: Motivación. Propósito. CIs  involucrados. Estimación de recursos necesarios para la implementación. Tiempo estimado. Estatus: que inicialmente será el de "registrado". Este registro deberá ser actualizado con toda la información generada durante el proceso para permitir un detallado seguimiento del mismo desde su aprobación hasta la evaluación final y cierre. La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos: Estatus actualizado: "aceptado", "rechazado", "implementado", ... Fecha de aceptación (denegación) del  RFC . Evaluación preliminar de la Gestión del Cambio. Prioridad y categoría. Planes de "back out". Recursos asignados. Fecha de implementación. Plan de implementación. Cronograma. Revisión post-implementación. Evaluación final. Fecha de cierre.
  • Aceptación Tras el registro del  RFC  se debe evaluar preliminarmente su pertinencia. Una  RFC  puede ser simplemente rechazada si se considera que el cambio no esta justificado o se puede solicitar su modificación si se considera que algunos aspectos de la misma son susceptibles de mejora o mayor definición. En cualquiera de los casos la  RFC  debe ser devuelta al departamento o persona que la solicito con el objetivo de que se puedan realizar nuevas alegaciones a favor de dicha  RFC  o para que pueda ser consecuentemente modificada. La aceptación del cambio no implica su posterior aprobación por el  CAB  y es sólo indicación de que se ha encontrada justificado su ulterior procesamiento. Clasificación Tras su aceptación se deben asignar a la  RFC  una prioridad y categoría dependiendo de la urgencia y el impacto de la misma. La prioridad determinará la importancia relativa de esta  RFC  respecto a otras  RFCs  pendientes y será el dato relevante para establecer el calendario de cambios a realizar. La categoría determina la dificultad e impacto de la  RFC  y será el parámetro relevante para determinar la asignación de recursos necesarios, los plazos previstos y el nivel de autorización requerido para la implementación del cambio. Aunque el rango de posibles prioridades pueda ser tan amplio como se desee se debería considerar una clasificación que incluyera, al menos, los siguientes niveles de prioridad: Baja:  puede ser conveniente realizar este cambio junto a otros cuando, por ejemplo, se decidan actualizar ciertos paquetes de software o se compre nuevo hardware, etc. Normal:  Es conveniente realizar el cambio pero siempre que ello no entorpezca algún otro cambio de más alta prioridad. Alta:  un cambio que debe realizarse sin demora pues esta asociado a errores conocidos que deterioran apreciablemente la calidad del servicio. El  CAB  debe evaluar este cambio en su próxima reunión y adoptar las medidas pertinentes que permitan una pronta solución. Urgente:  es necesario resolver un problema que esta provocando una interrupción o deterioro grave del servicio. Un cambio de prioridad urgente desencadena un proceso denominado cambio de emergencia que trataremos de forma independiente. La determinación de la categoría se basa en el impacto sobre la organización y el esfuerzo requerido para su implementación. El abanico de posibilidades incluye desde cambios que apenas requieren la participación del personal TI y que apenas modifican la calidad del servicio hasta cambios que necesiten grandes recursos y requieran de la aprobación directa de la Dirección. Los cambios menores pueden no necesitar la aprobación del  CAB  y ser implementados directamente. Cualquier otro cambio habrá de ser discutido en el  CAB  y se habrá de solicitar la colaboración de personal especializado para realizar tareas de asesoramiento.
  • La planificación es esencial para una buena gestión del cambio. Los sistemas de gestión de la información son muy susceptibles a los cambios de configuración por las sofisticadas interrelaciones entre todos los  CIs  involucrados. Un cambio aparentemente menor puede desencadenar una reacción en cadena con resultados catastróficos. Es imprescindible, como mínimo, disponer siempre de planes de "back out" que permitan la recuperación de la última configuración estable antes del cambio. Pero esto obviamente no es suficiente. En primer lugar el  CAB  debe reunirse periódicamente para analizar y eventualmente aprobar los  RFCs  pendientes y elaborar el  FSC  o calendario del cambio correspondiente. Para su aprobación el cambio se debe evaluar minuciosamente: ¿Cuáles son los beneficios esperados del cambio propuesto? ¿Justifican esos beneficios los costes asociados al proceso de cambio? ¿Cuáles son los riesgos asociados? ¿Disponemos de los recursos necesarios para llevar a cabo el cambio con garantías de éxito? ¿Puede demorarse el cambio? ¿Cuál será el impacto general sobre la infraestructura y la calidad de los servicios TI? ¿Puede el cambio afectar los niveles establecidos de seguridad TI? En el caso de cambios que tengan un alto impacto debe también consultarse a la dirección pues pueden entrar en consideración aspectos de carácter estratégico y de política general de la organización. Una vez aprobado el cambio (en caso contrario se seguiría el proceso ya descrito para el caso de no aceptación) debe evaluarse si este ha de ser implementado aisladamente o dentro de un "paquete de cambios" que formalmente equivaldrían a un solo cambio. Esto tiene algunas ventajas: Se optimizan los recursos necesarios. Se evitan posibles incompatibilidades entre diferentes cambios. Sólo se necesita un plan de back-out. Se simplifica el proceso de actualización de la  CMDB  y la revisión post-implementación.
  • Transcript

    • 1. GESTI Ó N DE LA CONFIGURACI Ó N DEL SOFTWARE GRUPO V
    • 2. Integrantes
    • 3. Índice
      • Introducción
      • Proceso GCS
      • Control de Versiones
      • Gestión de Cambios
      • Auditoría e Informes
    • 4. Introducción ¿Qué es? La Gestión de la Configuración del Software (GCS/SCM) es un conjunto de actividades diseñadas para identificar y definir los elementos en el sistema que probablemente cambien, controlando el cambio de estos elementos a lo largo de su ciclo de vida, estableciendo relaciones entre ellos, definiendo mecanismos para gestionar distintas versiones de estos elementos, y auditando e informando de los cambios realizados. ¿Cuál es el Propósito? Establecer y mantener la integridad de los productos de software a través del ciclo de vida del proceso de software. ¿Por qué es necesario? Los requerimientos del sistema siempre cambian durante su desarrollo y su uso, y se tienen que incorporar estos requerimientos en nuevas versiones del sistema. ¿Por qué es importante? Los cambios incontrolados aplicados a un proyecto de software lo llevan al fracaso.
    • 5. Actividades GCS
      • Planificación
      • Clasificación y Registro
      • Monitorización y control
      • Realización de auditorías
      • Elaboración de informes
    • 6. Ventajas
      • Resolución más rápida de los problemas.
      • Gestión de Cambios más eficiente.
      • Reducción de costes.
      • Control de licencias.
      • Mayores niveles de seguridad.
      • Mayor rapidez en la restauración del servicio.
    • 7. Desventajas
      • Una incorrecta planificación.
      • Estructura inadecuada de la CMDB.
      • Herramientas inadecuadas.
      • Falta de Coordinación con la Gestión de Cambios y Versiones.
      • Falta de organización.
      • Falta de compromiso.
    • 8. Índice
      • Introducción
      • Proceso GCS
      • Control de Versiones
      • Gestión de Cambios
      • Auditoría e Informes
    • 9.
      • CMM
      • Planificación de las actividades
      • de GC
      • 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
      Proceso de GCS
      • CM (Configuration Magnament)
      • Identificación
      • Control
      • Auditoria
      • Contabilidad de
      • Estado
      • 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
      • 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
    • 10. Proceso de GCS Categorías del resultado del proceso de ing. del software Tanto en forma de código fuente como ejecutable CCNP Datos Que describen esos programas, tantos técnicos como de usuarios Contenidos en el programa o externo a el. Documentos Configuración del software Programas de computadoras
    • 11.
      • -El cambio- [BER80]
      • Nuevos negocios o condiciones comerciales
      • Nuevas necesidades del cliente
      • Reorganización o crecimiento
      • Restricciones presupuestarias
      Ing. Yaniris Sepúlveda Gestión Configuración del Software Cambio
    • 12. Roles y Responsabilidades Gestor de configuración
      • Gestionar la planificación, identificación, control, seguimiento y auditoría de todos los elementos de configuración en la base de datos de configuración.
      • Desarrollar el plan de gestión de configuración.
      • Promover el uso efectivo de la CMDB.
      • Monitorizar y reportar los cambios no autorizados sobre los CIs.
      • Asegurar la consistencia e integridad de los datos de la CMDB a través de la ejecución de procedimientos de verificación y auditoría.
      • Liderar las actividades de evaluación del proceso: revisar tipos de elementos de configuración, relaciones, atributos y valores asociados, estructura de la base de datos, derechos de acceso.
      • Aprobar cambios estructurales en la CMDB.
      Coordinador de configuración
      • Asegurar que todos los CIs están registrados de forma adecuada en la CMBD.
      • Reportar cualquier discrepancia o no conformidad en los CIs al gestor de configuración.
      • Participar en la mejora continua del proceso de gestión de configuración.
    • 13. Roles y Responsabilidades Responsable de CIs
      • Asegurar que los CIs de los que es responsable están registrados en la CMDB con el estado y datos de configuración apropiados.
      • Verificar que los cambios sobre los CIs siguen el proceso de cambios definido.
      • Asegurar la idoneidad e integridad de los CIs de los que es responsable.
      Gestor de cambio
      • Evaluar el impacto y riesgo de los cambios.
      • Asegurar que los responsables de los elementos de configuración actualizan los históricos de estos elementos con los cambios implementados.
    • 14.
      • AccuRev
      • Perforce
      • ClearCase
      • Plastic SCM
      • SpectrumSCM
      • Surround SCM
      • Sablime
      • Smart Bear
      • SET-LIBER SET-LIBER
      • Harvest (CA).
      • Microsoft Proyect
      Herramientas
      • Telelogic Synergy (ehem. Synergy/CM, ehem. CM/Synergy, ehem. CCM)
      • Subversion
      • Git
      • Trac
      • Visual Source Safe (Microsoft)
      • Microsoft Team Foundation Server 2010
      • Microsoft Visual Studio 2010 ALM
    • 15.
      • Relación:
      • Descendiente
      • Interrelación
      • Procedimiento de identificación de los ECS.
      Elementos de configuración del Software (ICs)
    • 16. Ejemplos de ICs
      • - Planes
        • Plan de proyecto
        • Plan de calidad
        • Plan de gestión de configuración
        • Plan de gestión de riesgos
        • - Registros del proyecto
      • - Material de apoyo al cliente
      • - Especificación de requisitos
        • Requisitos de negocio
        • Requisitos de usuario
        • Requisitos de sistema
        • - Matriz de trazabilidad de requisitos
      • - Documentos de diseño
      • - Resultados de la resolución y análisis de decisión
      • - Código fuente
    • 17.
      • No impide los cambios justificados.
      • IEEE610-12-1990
      • Gestor de configuración.
      • Responsable del elemento
      • de configuración.
      • ECS.
      Líneas Base
    • 18. Líneas Base – Microsoft Project Visualización física
    • 19. Índice
      • Introducción
      • Proceso GCS
      • Control de Versiones
      • Gestión de Cambios
      • Auditoría e Informes
    • 20. Control de Versiones
    • 21. ¿Qué es un Control de Versiones?
    • 22. Luis G. Franco R. Importancia del Control de Versiones
    • 23.
      • Revisión
      • Línea base
      • Rama o Subversiones
      • Cambio o Delta
      • Rollback
      Funcionalidades
    • 24. Revisión
    • 25. Líneas Base
    • 26. Rama o Sub-Versiones
    • 27. Cambio o Delta
    • 28. Roll-Back
    • 29.
      • Microsoft Visual SourceSafe
      • Rational ClearCase
      • Mercurial
      • Bonsai CVS
      • TortoiseCVS
      Herramientas de Control de Versiones
    • 30. Índice
      • Introducción
      • Proceso GCS
      • Control de Versiones
      • Gestión de Cambios
      • Auditoría e Informes
    • 31. Gestión de Cambios
      • Objetivo
      • Que se realicen e implementen adecuadamente todos los cambios necesarios en la infraestructura y servicios TI garantizando el seguimiento de procedimientos estándar.
      • La Gestión de Cambios debe trabajar para asegurar que los cambios:
      • Están justificados.
      • Se llevan a cabo sin perjuicio de la calidad del servicio TI.
      • Están convenientemente registrados, clasificados y documentados.
      • Han sido cuidadosamente testeados en un entorno de prueba.
      • Se ven reflejados en la CMDB.
      • Pueden deshacerse mediante planes de "retirada del cambio" (back-outs) en caso de un incorrecto funcionamiento tras su implementación.
    • 32. Flujo de Gestión de Cambios
    • 33. Actividades Gestión de Cambios
      • Registro
      • Aceptación y Clasificación
      • Aprobación y Planificación
      • Implementación
      • Evaluación
      • Cambios de emergencia
    • 34. Registro
      • El primer paso del proceso de cambio es registrar adecuadamente las RFCs.
      • El origen de una RFC puede ser de muy distinta índole:
      • Gestión de Problemas.
      • Nuevos Servicios.
      • Estrategia empresarial.
      • Actualizaciones de software de terceros.
      • Imperativo legal.
      • Otro.
    • 35. Registro
      • La información de registro debe ser actualizada durante todo el proceso y debe incluir al menos :
      • Estatus actualizado.
      • Fecha de
      • aceptación/denegación.
      • Evaluación preliminar
      • de la Gestión del Cambio.
      • Prioridad y categoría.
      • Planes de "back out".
      • Recursos asignados.
      • Fecha de implementación.
      • Plan de implementación.
      • Cronograma.
      • Revisión post-implementación.
      • Evaluación final.
      • Fecha de cierre.
    • 36. Aceptación y Clasificación Aceptación Evaluación de su justificación. Proceder a rechazar o solicitar su modificación y devolver al solicitante. Clasificación Asignación de prioridad y categoría. Asignación del calendario de cambios a realizar. Asignación de recursos necesarios. La clasificación debe incluir, al menos, los siguientes niveles de prioridad : Baja , Normal , Alta , Urgente .
    • 37. Aprobación y Planificación
      • Para su aprobación el cambio se debe evaluar minuciosamente:
      • Beneficios vs. Costes asociados al proceso de cambio.
      • Riesgos asociados.
      • Disponibilidad de recursos necesarios.
      • Puede demorarse el cambio.
      • Impacto general sobre la infraestructura y la calidad de los servicios TI.
      • Afecta los niveles establecidos de seguridad TI.
      • Una vez aprobado el cambio debe evaluarse si este ha de ser implementado aisladamente o dentro de un "paquete de cambios" que formalmente equivaldrían a un solo cambio. Esto tiene algunas ventajas:
      • Se optimizan los recursos necesarios.
      • Se evitan posibles incompatibilidades entre diferentes cambios.
      • Sólo se necesita un plan de back-out.
      • Se simplifica el proceso de actualización de la CMDB y la revisión post-implementación.
    • 38. Índice
      • Introducción
      • Proceso GCS
      • Control de Versiones
      • Gestión de Cambios
      • Auditoría e Informes
    • 39. Auditoría de la Configuración
    • 40. Auditoría de la Configuración ¿Cómo aseguramos que el cambio haya sido aplicado correctamente ?
    • 41. Auditoría de la Configuración ¿Se ha hecho el cambio especificado en la orden? ¿Se ha seguido el proceso de desarrollo cumpliendo con los estándares? ¿Se ha seguido el proceso los procedimientos de la gestión de configuración de software? ¿Se ha actualizado adecuadamente los elementos de la configuración de software relacionados?
    • 42. Informe de Estado Que paso? Cuando paso? Quien lo hizo? Que mas se vio afectado?
    • 43. Informe de Cambios
    • 44. Diagrama de Actividades del Proyecto
    • 45. Fechas Importantes Tarea Fecha Descripción Planificación 2011-10-01 Esta tarea incluye el análisis de la nueva gestión de configuración Definición del Proyecto 2011-10-01 Esta tarea describe para cuando debe estar la definición Desarrollo 2011-10-02 Esta tarea describe para cuando debe estar el desarrollo Pruebas de Usuario 2011-10-05 Esta tarea define para cuando deben estar listas las pruebas de usuario.

    ×