Cuestión: No veo diferencias entre el control de versiones de los programas que llevamos, y la gestión de la configuración.
Por Maribel Sanchez-Segura; Doctora en Informática, Master en Ingeniería del Software, Profesora titular en la Universidad Carlos III de Madrid. Miembro del Software Engineering Lab sel.inf.uc3m.es
Si no sabes cuál es la diferencia entre control de versiones y gestión de la configuración (SCM software configuration management) estás haciendo un uso ínfimo de la potencia del proceso de gestión de la configuración. Si bien es cierto que la SCM contempla como una de sus prácticas el control de versiones, también es el único proceso que te ayuda a vigilar la consecución de los distintos productos entregables del proyecto así como a saber qué procesos o qué productos están afectados por un cambio realizado en cualquier producto durante el desarrollo de un producto software.
Si ahora estás pensando que realmente el proceso que te asegura la consecución de los hitos del proyecto es la planificación del mismo y el seguimiento, tengo que decirte que te equivocas de nuevo. Si no haces SCM, nadie te asegura que estés llevando a cabo lo planificado o incluso una última pregunta, si no haces SCM ¿Cuál es el mecanismo que te permite darte cuenta de que si modificas la estimación de tu proyecto deberías re-planificar? Sabes la respuesta porque está en tu cabeza, pero ¿y si fuera otra relación entre productos más compleja o desconocida por ti? ¿Te gustaría que hubiera un proceso que te lo recordara? Sí, pues ese es el proceso de gestión de la configuración.
Buen apunte, solo que al leerlo me queda una duda, o más bien curiosidad ¿entonces cualquier proyecto de desarrollo de software debe planificarse e incluir obligadamente el proceso de SCM? que hay de los proyectos en los que SCM no se toma en cuenta y simplemente se utilizar un “software” para llevar un control de versiones ¿están destinados a incumplir el plan del proyecto?
Buen apunte, solo que al leerlo me queda una duda, o más bien curiosidad ¿entonces cualquier proyecto de desarrollo de software debe planificarse e incluir obligadamente el proceso de SCM? que hay de los proyectos en los que SCM no se toma en cuenta y simplemente se utilizar un “software” para llevar un control de versiones ¿están destinados a incumplir el plan del proyecto?
Buen apunte, solo que al leerlo me queda una duda, o más bien curiosidad ¿entonces cualquier proyecto de desarrollo de software debe planificarse e incluir obligadamente el proceso de SCM? que hay de los proyectos en los que SCM no se toma en cuenta y simplemente se utilizar un “software” para llevar un control de versiones ¿están destinados a incumplir el plan del proyecto?
Buen apunte, solo que al leerlo me queda una duda, o más bien curiosidad ¿entonces cualquier proyecto de desarrollo de software debe planificarse e incluir obligadamente el proceso de SCM? que hay de los proyectos en los que SCM no se toma en cuenta y simplemente se utilizar un “software” para llevar un control de versiones ¿están destinados a incumplir el plan del proyecto?
Arturo, respondo a tus preguntas:
1 -¿entonces cualquier proyecto de desarrollo de software debe planificarse e incluir obligadamente el proceso de SCM?
Como sabes ningún proceso es obligatorio, luego no tienes por qué hacer ni planificación ni SCM. Ahora que si no tienes la calidad esperada no te puedes quejar.
2. ¿que hay de los proyectos en los que SCM no se toma en cuenta y simplemente se utilizar un “software” para llevar un control de versiones?
En estos casos, evidentemente si solo haces control de versiones, no podrás decir que haces gestión de la configuracion, sólo estas haciendo control de versiones y por tanto no podrás beneficiarte de las ventajas que aporta la gestion de configuración en su totalidad.
3. ¿están destinados a incumplir el plan del proyecto?
Simplemente no tendrán ningún mecanismo que vele por la integridad del proyecto. Si tuvieran un desastres en el proyecto contarían con menos mecanismos para defenderse y recuperarse del desastre o incluso ni se enterarían de que el desastre les ha sobrevenido, quizá hasta haber llegado a un punto en el desarrollo del proyecto donde el caos es total y el proyecto irrecuperable.
Arturo, respondo a tus preguntas:
1 -¿entonces cualquier proyecto de desarrollo de software debe planificarse e incluir obligadamente el proceso de SCM?
Como sabes ningún proceso es obligatorio, luego no tienes por qué hacer ni planificación ni SCM. Ahora que si no tienes la calidad esperada no te puedes quejar.
2. ¿que hay de los proyectos en los que SCM no se toma en cuenta y simplemente se utilizar un “software” para llevar un control de versiones?
En estos casos, evidentemente si solo haces control de versiones, no podrás decir que haces gestión de la configuracion, sólo estas haciendo control de versiones y por tanto no podrás beneficiarte de las ventajas que aporta la gestion de configuración en su totalidad.
3. ¿están destinados a incumplir el plan del proyecto?
Simplemente no tendrán ningún mecanismo que vele por la integridad del proyecto. Si tuvieran un desastres en el proyecto contarían con menos mecanismos para defenderse y recuperarse del desastre o incluso ni se enterarían de que el desastre les ha sobrevenido, quizá hasta haber llegado a un punto en el desarrollo del proyecto donde el caos es total y el proyecto irrecuperable.
Arturo, respondo a tus preguntas:
1 -¿entonces cualquier proyecto de desarrollo de software debe planificarse e incluir obligadamente el proceso de SCM?
Como sabes ningún proceso es obligatorio, luego no tienes por qué hacer ni planificación ni SCM. Ahora que si no tienes la calidad esperada no te puedes quejar.
2. ¿que hay de los proyectos en los que SCM no se toma en cuenta y simplemente se utilizar un “software” para llevar un control de versiones?
En estos casos, evidentemente si solo haces control de versiones, no podrás decir que haces gestión de la configuracion, sólo estas haciendo control de versiones y por tanto no podrás beneficiarte de las ventajas que aporta la gestion de configuración en su totalidad.
3. ¿están destinados a incumplir el plan del proyecto?
Simplemente no tendrán ningún mecanismo que vele por la integridad del proyecto. Si tuvieran un desastres en el proyecto contarían con menos mecanismos para defenderse y recuperarse del desastre o incluso ni se enterarían de que el desastre les ha sobrevenido, quizá hasta haber llegado a un punto en el desarrollo del proyecto donde el caos es total y el proyecto irrecuperable.
Arturo, respondo a tus preguntas:
1 -¿entonces cualquier proyecto de desarrollo de software debe planificarse e incluir obligadamente el proceso de SCM?
Como sabes ningún proceso es obligatorio, luego no tienes por qué hacer ni planificación ni SCM. Ahora que si no tienes la calidad esperada no te puedes quejar.
2. ¿que hay de los proyectos en los que SCM no se toma en cuenta y simplemente se utilizar un “software” para llevar un control de versiones?
En estos casos, evidentemente si solo haces control de versiones, no podrás decir que haces gestión de la configuracion, sólo estas haciendo control de versiones y por tanto no podrás beneficiarte de las ventajas que aporta la gestion de configuración en su totalidad.
3. ¿están destinados a incumplir el plan del proyecto?
Simplemente no tendrán ningún mecanismo que vele por la integridad del proyecto. Si tuvieran un desastres en el proyecto contarían con menos mecanismos para defenderse y recuperarse del desastre o incluso ni se enterarían de que el desastre les ha sobrevenido, quizá hasta haber llegado a un punto en el desarrollo del proyecto donde el caos es total y el proyecto irrecuperable.