Gestión de Configuración del Software (SCM)

La clase introduce el concepto de Gestión de Configuración del Software (SCM) como un proceso de apoyo gerencial clave para controlar la evolución de los sistemas. Se enfatiza la importancia de la integridad y trazabilidad, y se presentan los conceptos de elementos de configuración y repositorio, diferenciando entre sus áreas y tipos.

📌 Puntos clave

  • SCM (Software Configuration Management): Disciplina que controla y gestiona la evolución de los sistemas de software, asegurando su integridad y trazabilidad.
  • Elementos de Configuración del Software (ECS): No es solo código; incluye ejecutables, librerías, documentos, bases de datos y otros recursos del producto.
  • Repositorio: Estructura de directorios que almacena los ECS. Tiene tres áreas principales: trabajo, control de calidad y protegida.
  • Operaciones clave: Check-in, check-out, lock, unlock y merge, que permiten la transición entre áreas.
  • Tipos de repositorios: Centralizados (con bloqueos) y distribuidos (con fusión/merge).

🧠 Explicación

¿Qué es la Gestión de Configuración y Cambio (SCM)?

Es el proceso de aplicar procedimientos técnicos y administrativos para:

  • Identificar y definir piezas de software.
  • Controlar modificaciones y versiones.
  • Registrar y reportar el estado de cada pieza.
  • Asegurar la completitud, consistencia y correctitud del software.
  • Controlar el almacenamiento, manipulación y entrega de los productos.

Su objetivo principal es poder mirar hacia atrás y saber qué pasó para resolver problemas y reducir la incertidumbre sobre el estado del sistema. Responde preguntas como: ¿Qué elementos cambiaron y por qué? ¿Cuándo y quién realizó cierto cambio?

Elementos de Configuración del Software (ECS)

Son todos los componentes que integran el proyecto y necesitan ser gestionados. Esto va más allá del código fuente e incluye:

  • Ejecutables y librerías.
  • Documentación (manuales, especificaciones).
  • Bases de datos.
  • Casos de prueba y resultados.
  • Archivos de configuración.

El Repositorio

Es el lugar central donde se almacenan los ECS. Se divide en tres áreas principales:

  1. Área de Trabajo: Espacio donde los desarrolladores realizan cambios activos sin interferir con las versiones estables. Es un entorno libre para experimentar.
  2. Área de Control de Calidad: Aquí se gestionan archivos relacionados con pruebas. El código que llega aquí ya tiene un nivel de confianza y está listo para ser verificado e integrado.
  3. Área Protegida: Contiene las versiones estables y verificadas del software, listas para ser liberadas o entregadas al cliente. Los archivos aquí son inmutables o tienen un control estricto.

Operaciones y Tipos de Repositorios

  • Check-in: Transición del área de trabajo al área protegida (insertar cambios).
  • Check-out: Acceder al código estable del área protegida para trabajar en nuevas funcionalidades.
  • Lock/Unlock: Reservar un recurso (archivo) para uso exclusivo, común en repositorios centralizados.
  • Merge: Fusión de cambios de diferentes fuentes, común en repositorios distribuidos.

Los repositorios centralizados requieren bloqueos para evitar conflictos, mientras que los distribuidos permiten que cada quien trabaje con una copia completa y luego se fusionen los cambios.

📝 Detalles / Notas del profesor

  • Ejemplo de la Play 5: El producto completo no es solo la consola, incluye manuales y caja. Esto justifica que la gestión de configuración no se limite al código.
  • Ejemplo de cambio de IVA: Un cambio en el porcentaje del IVA es un requerimiento que debe ser trazable para entender por qué el sistema se comporta de cierta manera.
  • Anécdota laboral del profesor: En su trabajo (área de datos de un banco), usan un sistema de tickets para gestionar cambios. Cada cambio requiere un ticket que explica qué, por qué y qué requerimiento lo originó. La documentación se mantiene en Confluence.
  • Advertencia sobre la IA: Si la documentación no se mantiene actualizada, enviar documentación incorrecta a una IA puede causar problemas ("un token malgastado").
  • Importancia para el obligatorio: La estructura del proyecto debe poder responder preguntas como "¿dónde están los casos de prueba?" o "¿cómo vuelvo a la versión anterior?". El código del checkpoint debe estar en el área protegida.

✅ Checklist de repaso

  • ¿Puedo definir qué es la integridad y la trazabilidad en el contexto del software?
  • ¿Cuáles son los tres tipos de elementos de configuración del software y por qué es importante gestionarlos?
  • ¿Cuáles son las tres áreas de un repositorio y qué propósito tiene cada una?
  • ¿Qué diferencia hay entre un repositorio centralizado y uno distribuido?
  • ¿Qué preguntas clave debe poder responder un sistema con una buena gestión de configuración?
📄 Transcripción completa

De todo esto llegamos a entender que se aplicaba el concepto de ingeniería en el software y eso nos dio un ciclo de vida genérico Ese ciclo de vida genérico lo representamos con un esquema hecho con las más vanguardistas técnicas de diseño gráfico o sea en las cajitas de powerpoint que vimos la otra vez que no sé si esta diapola tiene como recap si no la busco no, no la tiene pero que nos hablaba de precisamente los procesos que constituían este ciclo genérico de software aquí está no, este es espectacular bien, entonces tenemos dos tipos de procesos los de ingeniería y los de apoyo gerencial ¿está? ¿está? bueno, entonces hoy vamos a ver uno de estos procesos gerenciales o de apoyo que es SCM ¿está? ¿está? ¿qué es la gestión de configuración y cambio? o en palabras más elegantes software configuration management entonces en la agenda ¿qué tenemos? que ya les aviso yo no estoy totalmente convencido que esta diapositiva la terminemos hoy pero vamos a comenzar ¿qué tenemos en la agenda? la definición de lo que es la gestión de la configuración del software y los elementos de configuración del software ahora ya que estamos hablando de que vamos a configurar el software y todo esto ¿ustedes se acuerdan que había una definición un poquito novedosa cuando hablábamos de software en la diapositiva anterior? porque decía aparte de la primera definición que decía ah, un conjunto de líneas que instrucciones que generan ta ta ta ta ta había otra que hablaba de documentos y ahí fue cuando yo eso y después yo le dije oh sorpresa la definición de software pasa de ser únicamente un sistema en ejecución a un producto completo que tiene otras cosas entre ellas una documentación que hablábamos de que mucha gente no le gusta y que otra gente sí y entre esas personas que bien esto nos interesa por una razón ¿cuál sería esa razón? que si vamos a hablar de gestión de la configuración del software no solamente vamos a hablar de código sino también de todo lo que implica el producto ¿sí? por ejemplo si usted se compra una play 5 no le viene la play y no más o sea tiene un papelito tiene un manual tiene una cosa o no lo mismo con un control y el producto completo es eso de hecho por alguna razón si compras un control usado si te viene en la cajita y con todo lo demás lo puedes vender a un precio diferente al que lo venderías si no lo tiene palabras más palabras más bien entonces ¿cómo va a ser la dinámica acá? yo inevitablemente voy a tener que leer la diapositiva pero después de eso lo voy a traducir a cristiano y lo vamos a conversar y Roxy va a hacer unos aportes bueno porque es un excelente porcentaje y sabemos ah bueno algo para transparentar un segundo es que Roxy y yo somos amigos entonces bueno la verdad que se nota la idea era no decir Roxy por lo menos dentro de un mes pero ya ya está sí sí se hizo lo que se pudo bien gestión de la configuración del software es la disciplina que controla y gestiona la evolución de los sistemas de software asegurando su integridad y trazabilidad a lo largo del ciclo de vida del producto aquí es donde yo empiezo a preguntar cosas porque aquí hay dos palabras que a mí me resultan muy interesantes integridad y trazabilidad ¿qué es algo íntegro? ajá ¿qué más? los que están en remoto también pueden hablar ojo algo completo ¿algo completo? ¿qué más? ok ¿Juan? que no se cada pedazo que no se cada pedazo algo que hace lo que tiene que hacer algo que hace lo que tiene que hacer imaginen un mundo así eh está perfecto y sobre todo algo que no se corrompe ¿verdad? porque incluso si hablamos de una persona íntegra bueno desde la perspectiva de los valores es porque bueno tiene unos valores que hace que no se corrompa y no se da el sistema habla de que haga lo que tiene que hacer no importa no importa el contexto hace lo que tiene que hacer íntegro ¿qué pasa? que como los sistemas van evolucionando y van creciendo porque el tiempo pasa y las necesidades también cambian ahí es donde el interés se puede ir bueno fui creciendo pero se me fue cayendo el pelo no sé y al sistema le va pasando algo parecido pero tenemos un proceso llamado gestión de la configuración del software que busca que esto no suceda luego tenemos la palabra trazabilidad ¿eso qué será? seguimiento que se le hace en el tiempo el producto ¿otra vez? seguimiento que se le hace el producto en el tiempo bien me gusta también puedes medirlo ¿qué cosa? medir qué? que algo que es trazable también lo puedes medir y puedes medir qué pasó o cuándo sucedió también muy bien ¿qué más? bueno fíjense que de forma inherente sale la palabra problema porque en algún momento tiene que haber un problema ¿no? no vas a ver una traza porque funciona vas a ver una traza porque hay paro exactamente exactamente exactamente y eso es importante porque si estamos hablando de sistemas que crecen en algún momento van a haber este tipo de situaciones y hay que saber remediarla ¿sí? bien definición de CCM es el proceso de aplicar procedimientos técnicos y administrativos a lo largo del ciclo de vida para identificar y definir piezas de software controlar modificaciones y versiones registrar y reportar el estado de cada pieza asegurar la completitud consistencia y correctitud de las piezas del software y controlar el almacenamiento manipulación y entrega de los productos del software ¿esto qué significa? básicamente esto significa yo necesito poder mirar hacia atrás y saber qué pasó para cuando haya un problema también esto nos va a ayudar a reducir un poquito la incertidumbre de cómo está el sistema tendrías que poder responder a ciertas preguntas a partir de esto ¿sí? recordemos al final no estamos hablando solamente de código sino de otros componentes que hacen del producto algo ¿ok? ¿qué va a ser lo más natural en una profesión de desarrollo de software como tal? bueno identificar esto a nivel código pero no es lo único es como el llamado que estoy tratando de hacer ahora es como disconizar el sistema el código ¿cómo así? o pasar a palabras lo que hace el sistema o sea no exactamente hay un poco de eso pero no es el concepto completo ¿qué pasa? que si yo un día tengo un código que ejecuta un algoritmo que hace un cálculo ¿verdad? digamos un cálculo de IVA que tiene un porcentaje en algún momento del tiempo pero pasan los años y hay un anuncio de que hubo un cambio en los porcentajes del IVA bueno ya el sistema no va a hacer un cálculo con un número sino que lo va a hacer con otro entonces la trazabilidad ¿qué me va a permitir ver? ¿cuál fue el requerimiento que hizo que el sistema tenga ese número nuevo y por qué sucedió? no es que eso lo que me permite es poder evidenciar que el comportamiento del sistema tiene una tiene un contraste contra algo y que no salió de la nada y si sale de la nada es porque es un boco ¿sí? esto ustedes lo van a hacer no se preocupen ¿qué actividades hay? ¿por qué hablamos de actividades? porque esto al final es un proceso y los procesos tienen actividades no pierdan de vista eso gestión de cambios control de versiones y gestión de la configuración ¿por qué es importante la gestión de cambios? y esto se puede asociar de repente a procesos más tradicionales pero en realidad en Agile esto también sucede porque de vuelta nosotros hablábamos que el software tenía como propósito solventar un problema y no convertirse en otro problema ¿cierto? ¿qué pasa? que el problema que va a solucionar puede ir mutando en el tiempo un ejemplo claro es como el que les di ahora el tema del porcentaje del IVA pero pueden haber muchas otras cosas reglas de negocio o cosas externas al negocio que incidan en cambios forzososs ¿sí? entonces ¿qué ocurre? que como se llegó a un acuerdo en determinado momento para que un sistema haga algo si hay una inserción de un cambio de ese comportamiento eso tiene que estar bien especificado y se tiene que poder ir a visitar hacia atrás y hacia adelante lo que usted necesite ¿por qué? porque al final cuando estas cosas no se controlan de la forma correcta empiezan a existir vacíos conceptuales que terminan en pérdida de plata o para el desarrollo o para la persona que está adquiriendo el producto ¿por qué? porque si no se controló ese cambio bien entonces nuevos comportamientos pueden ser no esperados más allá de que se hayan hablado el control de versiones tanto para el código como para documentación para lo que sea persigue más que todo este mismo propósito ¿no? de poder ir hacia atrás y hacia adelante sobre todo para saber el estado del sistema en distintas instancias o momentos igual cuando estemos en la parte más práctica de Git lo vamos a poder ver con más claridad y gestión de la configuración identificación y control de los elementos de configuración del software elementos de configuración del software ¿qué es eso? lo vamos a ver más adelante pero se acuerdan que les había dicho que teníamos preguntas para responder con todo este proceso del SCM tenemos esta ¿qué elementos cambiaron y por qué? ¿cuándo y quién realizó cierto cambio? ¿esto por qué será? porque alguien siempre se la manda y hay que ver cómo fue o qué pasó ahora ahora dímelo desde palabras de un espíritu colaborativo porque siempre surgen errores en el momento de desarrollo y puede ser que se realicen de manera poco responsable y pues bueno está suceden las cosas hay resentimiento miren yo le voy a decir algo así como a veces hacemos sobre aclaraciones que vienen desde la experiencia hay anécdotas de ustedes que vienen desde la experiencia y también se notan pero ¿qué pasa acá? esto es importante por dos razones la primera porque si algo está dando problemas la mejor fuente de información es la persona que lo hizo ya está segundo porque si salió bien bueno vamos arriba ¿no? otra cosa que también es importante en esto es que si se puede llegar a saber quién hizo cierto cambio y hay que hacer una transferencia de conocimiento bueno la mejor persona es esa la transferencia de conocimiento suele ser un tema sensible así que vamos a a seguir hacia adelante ¿qué otro problema resuelve? responder a la pregunta ¿dónde están los casos de prueba? fíjense que ya no estamos hablando del código acá ¿dónde guardo la documentación? ¿qué archivos se necesitan para construir un entregable? ¿qué versión tiene instalado cierto cliente? ¿cómo vuelvo a la versión anterior? esto es importante también sobre todo cuando publicamos algo que termina en un ups, ups, ups mentira, mentira, mentira y tenemos que saber cuál es la versión a la cual volver que no nos deje en este estado tan expuesto y es posible hacer un experimento separado antes de hacer un cambio ¿qué pasa? como estamos hablando de un proceso de gestión o de apoyo o gerencial o como lo quieran decir no es un proceso dedicado a producir el software pero lo administra y es importantísimo ¿y qué pasa? no lo hemos visto todavía pero la estructura en la que ustedes van a hacer el obligatorio tendría que poder responder estas preguntas por eso es que estas preguntas les interesan ¿sí? entonces son preguntas que se pueden hacer para ustedes antes de preguntarnos a nosotros pero ¿cómo es el tema? bueno para si lo que tengo acá al frente me responde todas estas preguntas estoy bien ahora si yo no puedo acceder a ciertas cosas responden estas preguntas en su repo capaz hay algo que le va a quitar nada posiblemente hasta acá alguna pregunta perfecto no para esto no algo para decirles esto es primero que nada estamos pensando a nivel de proceso todavía no estamos pensando en ninguna tecnología en particular o sea todo esto que estamos viendo ahora si bien nosotros ya sabemos cómo lo vamos a aplicar y con lo que va a venir ahora esto es como un nivel antes ¿no? o sea no importa en qué lo vamos a sacar esto es simplemente a nivel proceso teóricamente ¿no? y después otra cosa que quería contarles como para bajarle un ejemplo que es bueno ¿cómo lo hago mi trabajo? que nosotros no usamos ni GitHub tenemos como un sistema de etiquetaje entonces en andame a decir en esta parte de gestión de cambio nosotros lo que hacemos es yo les dije que trabajo en la parte de datos entonces nosotros tenemos nuestros programitas de datos para extraer tomamos varias tablas hay distintas fuentes de datos y ahí tomamos lo que nos sirve y lo volcamos a otro lado ¿eh? son serreves no no no no no nosotros

Built with LogoFlowershow