un pequeño resumen de los capitulos 8, 9 y 10 del libro Fábricas de software: Experiencias tecnológicas y organización

1. Capítulos 8,9 y 10
Ugarte Vera, Nilton 09200067

2. 1. Gestión de la Configuración de
Software(SCM)
• Cómo estructurar la producción de software y cómo sacar provecho
de las economías de alcance en una verdadera fábrica de software.
(Greenfield,2004).
• Un porcentaje elevado de empresas, incluyendo fábricas de software,
no utilizan ningún tipo de sistema o no suelen pasar de un uso muy
primitivo.
• La responsabilidad de SCM es identificar:
• Cúando se produce el cambio.
• Por qué se produce el cambio.
• Quién introduce el cambio.

3. 1.1 SCM y Construcción De Software
• Entre el 30 y el 70 % del tiempo de un proyecto se invierte en la fase
de contrucción (McConnell, 2005).
• En Software todo es diseño por lo que la construcción es una fase del
diseño detallado (Martin, 2002).
• Como herramientas indispensables tenemos:
• Editores y compiladores.
• Depuradores, profilers y controles de versiones.
• Herramientas de control e incidencias.

4. 1.2 Mitos de la SCM
• Solo es importante en equipos grandes.
• Caso : patrón branch per task (Berczuck, 2002) eficaz incluso con un solo
desarrollador.
• Control de versiones limitado es suficiente.
• Caso : Pérdida de oportunidades, productividad, eficacia, y control.

5. 1.3 Problemas debidos a la no utilización de
las herramientas y técnicas SCM adecuadas
• Problema de software perdido .
• Destrucción de código.
• Enlaces desaparecidos.
• Desestabilización de la línea principal.
• Identificación incorrecta de los elementos que componen una entrega
concreta.
• Imposibilidad de conocer qué cambios desencadenó una incidencia o
bug concreto.

6. 1.4 Pilares básicos en construcción de
software
• Control de versiones.- Para coordinar el trabajo y gestionar
cambios.
• Control de tareas y defectos.- cada cambio tendrá asociado una
tarea, una descripción adecuada, imputaciones de horas, registro
de quién hace el cambio, versión detectada, prioridad, entre
otros.
• Pruebas sistemáticas.-
• Tests unitarios: verifican tareas individuales de los programadores.
• Tests de integración: Aplicadas cuando se crea una nueva línea base o
release.
• Tests manuales: dirigidas por guiones de prueba (sistemáticas).

7. 1.5 Desarrollo paralelo vs. Desarrollo en serie
• Desarrollo serializado.- Implica realizar cambios bloqueantes, tiene un
elevado impacto negativo sobre la productividad del desarrollo, así
como no es capaz de permitir la evolución del software en líneas
paralelas reales. Presenta falta de estabilidad en la línea principal.
• Desarrollo paralelo.- Posee una línea principal, línea de
mantenimiento y una serie de ramas secundarias de menor duración
que se corresponden con tareas, principales ventajas:
• El programador puede realizar check ins como considere necesario, durante el
tiempo que resuelva la tarea.
• Los cambios no pasan mucho tiempo fuera del control de versiones.
• El desarrollar podrá subir todos los cambios a la ramas incluso si no están
terminados y podrá retomarlos o reasignarlos.
• La integración ahora es un proceso controlado y centralizado.

8. 1.6 Integración continua vs. controlada
• Integración continua.- asociada al desarrollo serializado, donde el
código ya está en la línea principal, que ha sido desestabilizada.
• Integración controlada.- más adecuada en fábricas de software,
siempre hay un responsable de la entrada de elementos en la línea
principal que cuidará que no se desestabilice.
• Herramientas que comparten tanto la integración continua y la
controlada:
• Disparar una compilación cuando se termina una tarea.
• El integrador usará el sistema para hacer pruebas sobre la rama principal
cuando cree nuevas versiones.

9. 1.7 Conclusión
• A pesar de que la gestión de la configuración de software es
importante en la construcción de software, muchas empresas hacen
un uso deficiente de la misma o simplemente la ignoran.
• SCM puede mejorar sensiblemente la productividad de los equipos de
desarrollo y el control de proyectos.

10. 2. Desarrollo Global de Software (GSD)
• Lo que tradicionalmente era un equipo que se reunía periódicamente
para conversar y debatir cara a cara, ha pasado a ser un equipo
virtual, una red de sub equipos.
Misma Organización Diferente Organización
Mismo lugar Desarrollo co-localizado. Desarrollo co-localizado con
subcontratación (outsourcing).
Mismo país Desarrollo distribuido (DSD) Desarrollo distribuido (DSD) con sub
contratación (outsourcing).
Otro país Deslocalización
Desarrollo global (GSD) (offshoring)
Subcontratación deslocalizada
Desarrollo global (GSD)(offshore
outsourcing).
Tabla de propia elaboración, tomando como referencia la tabla 9.1 del libro
“Fábricas de software: Experiencias tecnológicas y organización”.

11. 2.1 Beneficios de GSD
• Aprovechar la diferencia horaria para lograr jornadas laborales más
largas y conseguir mayor productividad.
• Minimizar costes de desarrollo.
• Localización de desarrolladores más cerca del cliente.
• Obtener ventajas de la diversidad de experiencias de stakeholders
distribuidos.

12. 2.2 Los desafíos de GSD
• Comunicación inadecuada.- la comunicación informal genera bajos
niveles de confianza entre colegas.
• Diversidad cultural.- al no compartir lenguaje nativo debe utilizarse
un lenguaje alternativo(inglés), otro problema es diversos significados
para la misma palabra, así como algunas expresiones o
comportamientos pueden parecer ofensivas o bruscas para otras.
• Diferencia horaria.- Falta de comunicación sincrónica.

13. 2.3 Herramientas de apoyo al trabajo en
grupo distribuido (groupware)
• Emails .
• Listas de correos.
• Grupos de noticias.
• Foros de discusión.
• Documentos compartidos.
• Mensajería instantánea.
• Pizarras de dibujo compartidas.
• Chat.
• Videoconferencias.

14. Estrategias para minimizar problemas en GSD
Necesidad Motivación Prácticas