Desarrollo de Software a Distancia Gestión de Software 2006

Desarrollo de Software a Distancia Gestión de Software 2006
Germán Viera Ariel Ron Julián Magnone

Agenda Introducción Caso de estudio: SEGAL Calidad
Áreas Claves Calidad en la Comunicación Calidad en Proyectos Open Source Proyecto de Ingeniería de Software

Introducción ¿Qué entendemos por Desarrollo de Software a Distancia?
Proyectos en los cuales alguno (o algunos) de los involucrados se encuentra en sitios geográficos diferentes. Clientes Proveedores Conocido como GSD: Global Software Development DSD: Distributed Software Development CSD: Collaborative Software Development ¿Qué entendemos por Desarrollo de Software a Distancia? Proyectos en los cuales alguno (o algunos) de los involucrados se encuentra en sitios geográficos diferentes. Involucra tanto a proveedores como clientes, quienes pueden estar localizados en lugares geográficamente distintos. También es conocido como GSD, DSD, CSD, etc.

Introducción (2) ¿Por qué investigar el Desarrollo de Software a Distancia? Fenómeno en aumento Reciente aparición Impacto directo en: Gestión de Procesos Calidad Realidad en la industria de software local ¿Por qué investigar el Desarrollo de Software a Distancia? Impacto directo en: Gestión de Procesos: Lograr que los métodos utilizados permitan abstraer los procesos de la organización como un “TODO” por más que esté distribuida. Lograr una abstracción de homogeneidad. Tanto para el cliente y el proveedor. Calidad: Adaptar la metodologías de calidad usuales y estandarizadas a la realidad distribuida. Enfoque en la calidad de comunicación y coordinación, que son los principales problemas en un desarrollo distribuido. Fenómeno en aumento. Reciente aparición. El problema del año Avances tecnológicos y de las telecomunicaciones. Reducción de costos en las telecomunicaciones. Realidad en la industria local. Impacta fuertemente en nuestro entorno como oportunidad de crecimiento y expansión de mercados.

Introducción (3) Posibles escenarios Cliente a Distancia
Desarrollo on-site off-shore Proveedor Distribuido Open Source Distributed Model Presentamos aquí algunos posibles escenarios identificados en desarrollos de software a distancia.

Introducción Caso 1 Cliente a Distancia Proveedor de Software Cliente Este esquema muestra a un proveedor en un sitio completamente distinto al del cliente. Es posible que nunca haya interacción persona a persona entre cliente y proveedor. La interacción es posible gracias a Internet y a los avances en las comunicaciones. Este esquema también aplica tanto a organizaciones pequeñas como grandes. Incluso, y dependiendo de la “imagen” de los proveedores, un cliente podría creer que está tratando con una organización de un tamaño considerablemente distinto al que realmente es. Esto también aplica a la inversa. Un ejemplo de pequeña organización puede ser una sola persona (desarrollador, programador, etc.) que ofrezca sus servicios a través de Internet. Un ejemplo de gran organización podría ser una empresa que, a través de un canal de ventas en el exterior, consiga un potencial cliente al cual desarrollar un producto de software a distancia. Proveedor en sitio geográfico distinto al del Cliente Sin contacto persona-persona ej. a través de Internet Diferentes tamaños de organizaciones

Desarrollo on-site off-shore
Introducción Caso 2 A Desarrollo on-site off-shore Proveedor de Software Cliente Grupo del Proveedor. El esquema representa un proveedor que envía un equipo de trabajo al lugar del cliente. Este esquema aplica a organizaciones proveedoras de software quizás no tan pequeñas, dado que requiere contar con cierta infraestructura para el envío del grupo por parte del proveedor hacia el lugar del cliente, quizás involucrando viajes, estadías en el exterior, viáticos, lo que implica cierto control de logística. Proveedor en sitio geográfico distinto al del Cliente Proveedor envía al sitio del cliente un grupo de profesionales para: Construcción del Producto Consultoría Organizaciones quizás no tan pequeñas

Desarrollo on-site off-shore
Introducción Caso 2 B Desarrollo on-site off-shore Proveedor de Software Cliente Grupo del Proveedor. Grupo Cliente El cliente contrata un grupo de la organización, para realizar tareas concernientes al cliente. Por ejemplo, desarrollar un producto que el grupo del cliente esta construyendo, o instruir al cliente en un nuevo negocio que esta estableciendo. El cliente lo que adquiere es personal calificado (consultoría, auditoría, capacitación). El cliente solicita la construcción de un producto que requiere de desarrollo en on-site por razónes de seguridad o logísitica. Un grupo del Proveedor es enviado al Cliente Posible razón: Recursos Calificados Seguridad Logística

Proveedor Distribuido
Introducción Caso 3 Proveedor Distribuido Desarrolladores Cliente Proveedor Analistas de Negocio La estructura de la organización del proveedor es completamente distribuida. El esquema puede aplicarse tanto para organizaciones pequeñas o grandes. Podemos identificar este tipo de escenarios en países del primer mundo, que aprovechan el fenómeno de desarrollo a distancia para ofrecer sus productos utilizando recursos (desarrolladores, analistas, infraestructura, etc.) en una ubicación geográfica diferente con el objetivo de reducir costos y aumentar ganancias. No es necesario que el proveedor sea una organización establecida, sino que entra en juego el concepto de organización virtual (se encarga de la gestión del proyecto, utiliza recursos freelance, delega tareas y actividades, tiene contacto con el cliente). Por ejemplo, desarrolladores freelance, analistas de negocio contratados, gestión elaborada por consultores, etc. La estructura del proveedor es distribuida Abstracción del Proveedor como un “todo”

Open Source Distribución total
Introducción Caso 4 Open Source Políticas Documentación Gestión Estrategia Ingeniería etc. Comunidad Existe una distribución total, de políticas, de documentación, de gestión, etc. Más que el concepto del Cliente, se maneja el concepto de Usuarios. El producto podía surgir de alguna necesidad de los involucrados o de la comunidad. Colaboración basada principalmente en bases de conocimiento y en herramientas de discusión (repositorios, foros de discusión, Web Blogs). Distribución total El producto surge de la necesidad de los involucrados Bases de Conocimiento Concepto de Usuarios

Ventajas del Desarrollo a Distancia
Ventajas para el “Cliente” Reducir costos Permite enfocarse en sus procesos de negocio. Mejora la eficiencia. Acceder a mano de obra calificada. Ventajas para el “Proveedor” Nuevos mercados a nivel global. Oportunidades en mercados reducidos. Las ventajas del desarrollo de software distribuido son notorias, tanto para el cliente como para los proveedores que ofrecen estos servicios. Para el cliente: La contratación de servicios off-shore implica una reducción, quizás importante, de costos. Tercerizar permite a la organización que actúa como Cliente, enfocarse en sus procesos de negocio y mejorar la eficiencia del mismo. Acceder a mano de obra calificada que puede no estar disponible en la organización del cliente. Utilizar los recursos del lado del cliente que quedan libres en otras tareas de la organización que requieren de sus conocimientos. Para el proveedor: - Permite extender sus mercados a nivel global. En particular, en mercados reducidos implican una oportunidad de expansión explosiva y prácticamente sin límites.

Inconvenientes Problemas conocidos en el desarrollo de software a distancia Comunicación Distancia Herramientas y métodos Coordinación ej. Actividades Diferencia Cultural Diferencia Horaria Si bien se cuenta con gran cantidad de ventajas en el desarrollo de software a distancia, son también notorias las desventajas: Comunicación juega un papel esencial en el desarrollo a distancia. La comunicación es un factor decisivo que puede determinar el éxito o fracaso del proyecto. La coordinación, por ejemplo de actividades y recursos, también se ve afectada debido a la distancia. Diferencia Cultural refiere a diferencias de idioma, de gustos, sensaciones de responsabilidad, etc. que pueden provocar una dificultad para el entendimiento, priorización de requerimientos, de necesidades, etc. Diferencia Horaria, afecta directamente sobre las comunicaciones sincrónicas. EEUU-India la diferencia horaria es importante.

Caso de Estudio: SEGAL Software Engineering and Global interAction Laboratory Objetivo Explorar y estudiar el desarrollo de software a distancia (GSD), con equipos de desarrollo… distribuidos geográficamente con diferencia horaria Dr. Daniela Damian University of Victoria, Canada

Caso de Estudio: SEGAL (2)
Áreas de Interés Entender los problemas que enfrenta el desarrollo de software con/en organizaciones distribuidas. Estudiar herramientas y tecnologías que permitan mejorar la colaboración. Human-Computer Interaction (HCI) Paper “Requirements Engineering challenges in multi-site software development organizations”, Dr. Daniela Damian, 2003 El SEGAL tiene como principal interés estudiar los problemas que enfrenta el desarrollo de software con/en organizaciones distribuidoras. También plantea estudiar herramientas y tecnologías que faciliten e intenten resolver los principales problemas: Coordinación, Comunicación. Este último aspecto tiene fuerte relación con Interacción Persona Computadora. Esta área de investigación también toca de cerca de Dr. Daniela Damian. El ejemplo brindado en la presentación se basa en el Paper “Requirements Engineering challenges in multi-site software development organizations”, Dr. Daniela Damian, 2003.

Resultados en base a estudios empíricos Propuesta de desarrollo de un proyecto real Grupos distribuidos Actividades del Proceso distribuidas Negociación, Relevamiento de Requerimientos, Desarrollo, Testing, etc. 8000KLOC cada liberación 12 a 18 meses de desarrollo 120 desarrolladores Full Time

Ubicación geográfica de los involucrados Cliente distribuido mundialmente. Gestión del Proyecto en EE.UU. Gestión de Ingeniería de Software en Australia Desarrolladores en Australia y Nueva Zelanda

Resultados del estudio El conjunto de problemas conocidos derivan en retos a resolver. El paper concluye con recomendaciones de cómo encarar cada uno de éstos problemas. El Paper hace mayor hincapié en los requerimientos, por ser una de las actividades decisivas en el éxito del proyecto, y en la que tiene mayor impacto los problemas anteriormente descritos (comunicación, coordinación, etc.)

Herramientas y Tecnologías Video y Audio IM Software colaborativo

India ¿Por qué India? Principal Inconveniente Ingenieros calificados
Alta motivación Salarios reducidos Buen dominio del idioma inglés ingenieros se reciben cada año Principal Inconveniente Diferencia Horaria con EE.UU.

Calidad en el Desarrollo de Software a Distancia

Calidad en el Desarrollo a Distancia
Gestión de Calidad basada en estándares Una implementación más de: CMM ISO Áreas claves a tratar por los grupos QA Calidad del Producto y Proceso. Calidad de la Comunicación. En los proyectos de Desarrollo a Distancia al igual que en los proyectos normales, los estándares de calidad son utilizados como guía hacia el éxito del proyecto al basarse en la Satisfacción del Cliente. La calidad del producto y proceso son siempre áreas clave sin importar la distribución del proceso. La calidad de la comunicación siempre es un punto clave en todo proyecto. En los proyectos distribuidos, una variación no aceptable de la calidad puede poner en riesgo todo el proyecto. Controlar la comunicación dentro de los parámetros aceptables es responsabilidad de los encargados de calidad.

Calidad de la Comunicación
Área Clave. Requiere un análisis cualitativo y/o cuantitativo desde el kick-off del proyecto. Informalidad o prácticas no estandarizadas pueden concluir en el fracaso del proyecto. En todo proyecto de desarrollo a distancia, la comunicación es un área clave. Ya en las primeras interacciones con el cliente en el inicio del proyecto se requiere un análisis cuantitativo/cualitativo de la calidad de la comunicación, dado que si esta se aleja mucho de los parámetros aceptables, puede ser determinante para el éxito del proyecto. Así también, la informalidad o prácticas no estandarizadas pueden concluir en el fracaso del proyecto.

Calidad de la Comunicación (2)
QA de la Comunicación Mencionada explícitamente en la mayoría de los estándares de Procesos, aunque sin profundizar. CMM Contempla la importancia pero sin definir actividades de medición ni control. La calidad de la comunicación se menciona en la mayoría de los estándares de procesos pero no se profundiza en detalle en éstos estándares. Por ejemplo en CMM se contempla la importancia de ésta pero no se definen actividades ni de medición ni de control.

Compromiso con la estabilidad de la calidad de comunicación. Cláusulas contractuales. Compromiso del cliente con el proveedor. Acuerdos en las instancias de interacción.

Temas a Evaluar y/o Medir: Detalles Estratégicos. Detalles Culturales. Distribución del conocimiento. Diferencia Horaria. Mantener el Ciclo de Comunicación. Herramientas de comunicación. Gestión del Proyecto y Proceso. Detalles Técnicos.

Detalles Estratégicos: Información proveniente de diferentes entidades Consistencia Independencia Información digerida hacia la Alta Gerencia Facilitar la toma de decisiones

Detalles Culturales: Evaluar la capacidad de comprensión de las diferentes entidades. Intersección Disyunción Evaluar factibilidad de estandarización de la comunicación. Comunicación Administrativa Comunicación Técnica Sensaciones de responsabilidad diferentes Oriente Occidente

Diferencia Horaria: Aprovechar al máximo las interacciones. Elaborar metodologías de comunicación asincrónica. Medir la calidad de las interacciones Preguntas antes, respuestas después. Evaluar si los objetivos fueron cumplidos. Aprovechar al máximo las interacciones, minimizando los costos de comunicación.

Mantener el Ciclo de Comunicación:

Mantener el Ciclo de Comunicación: Cliente Gerencia Gestión Proyecto Ingeniería

Mantener el Ciclo de Comunicación : Cliente Gestión Calidad Arquitectura y Diseño Requerimientos Desarrollo

Herramientas Sincrónicas o Asincrónicas Tiempo Real Texto, voz, video Basadas en colaboración estandarizada, o en repositorios Maximizar comunicación sin olvidar la minimización de costos. Punto a punto o a través de red de distribución.

Distribución del Conocimiento
Conocimiento del negocio a los desarrolladores, analistas y diseñadores. Políticas de la organización. Entrenamiento en herramientas. Metodologías de trabajo, utilización de estándares. Decisiones de la gerencia. Estado actual del proyecto. Digestión de métricas. Obtención de métricas.

Calidad en Proyectos Open Source

Calidad – Open Source Aplicado por Organizaciones más conocidas
Apache Java Net Objetivos Calidad del Producto. Automatización de la Verificación. Feedback constante de los usuarios. Independencia del Proceso. Lineamientos de Calidad acordes a los de la organización.

Calidad – Open Source (2)
Especificación Solicitud Base de Conocimiento QA Aseguramiento de la Calidad (Grupos de Discusión) EL comienzo del proyecto generalmente viene dado por la implementación de una especificación o la solicitud de un proyecto en particular. El grupo de QA de la organización realiza un análisis para validar que la especificación es realizable por la organización. Es decir, si la especificación cumple los estándares necesarios para presentarse como propuesta, si cumple con los términos legales necesarios para la implantación como proyecto open-source, si las tecnología a utilizar se adaptan a la especificación. El proceso comienza con la incorporación de la especificación a la base de conocimiento de calidad, la cual es accedida por los encargados de calidad de la organización a las tareas de evaluación. Las revisiones se basan en grupos de discusión. En Apache y Java Net estos grupos se encuentran localizados en un sitio geográfico común, pero en el caso de Object Web, los encargados de evaluación inicial de QA se encuentran distribuidos en América y Europa. Sin importar la distribución la mecánica es similar. Profesionales de la organización analizan la propuesta, aplican un conjunto de check lists a la misma y presentan sus resultados al expositor. La evaluación puede rechazar el proyecto o puede pasar a la etapa de incubación. La transición se realiza desde la base de conocimiento de QA hacia la base de incubadora. Esta transición es responsabilidad del grupo de QA . En caso de rechazo de propuesta puede ocurrir que se solicite una nueva instancia de evaluación por temas concernientes a la calidad de la especificación (requiera ajustes) o simplemente se rechace por no cumplir los requisitos necesarios o los objetivos de la organización. Tener en claro que la etapa de evaluación inicial no estudia viabilidad del proyecto ni realiza ningún tipo de planificación ni análisis de riesgos.

Gap Análisis (Paso previo al inicio) Asignación de Roles Base de Conocimiento QA Base de Conocimiento Incubadora Adoptar Modelo de Proceso Aseguramiento de la Calidad Objetivos de Calidad del Producto y de Uso Una vez realizada la transición desde la revisión inicial de calidad se incorpora la especificación a la base de conocimientos de incubación. En esta etapa comienza el estudio de viabilidad y se presenta al resto de los usuario en solicitud de integrantes. Se definen los roles y se demarcan los primeros objetivos. Se presentan los objetivos de calidad del producto y calidad de uso analizando las necesidades del publico objetivo (desarrolladores, usuario final). Se asignan las responsabilidades de calidad y comienza el trabajo de las mismas estudiando la especificación. Se presenta el modelo de proceso a utilizar. El grupo de calidad se encuentra íntimamente ligado a las decisiones a tomar. Se evalúan herramientas y metodologías. Cada proyecto tiene un grupo de calidad designado que se encarga de las responsabilidades de calidad del proyecto en sí. El grupo de calidad estudia la viabilidad de automatización. Antes del inicio del proyecto se deben demarcar las necesidades de verificación para asegurar el éxito del proyecto. Una vez definido el grupo de gestión se estudian las metodologías de análisis de decisión buscando sincronizar las mismas con aquellas demarcadas por los estándares de la organización. El proceso definido de la organización hace hincapié en la visibilidad sobre el proyecto. Se evalúa el modelo de proceso y su adaptación al modelo definido por la organización. Notar que según la naturaleza del proyecto la organización cuenta con varios modelos definidos a adoptar. La información generada por la evaluaciones de calidad del grupo de calidad designado del proyecto se persisten en la base de conocimiento de Calidad. (La información de cada proyecto es evaluada por el grupo de calidad de la organización. Esta información es necesaria para la historia de la organización así para tomar decisiones correctivas sobre inconvenientes presentes en mas de un proyecto) Grupo de Calidad Designado

Base de Conocimiento Proyectos Aseguramiento de la Calidad Base de Conocimiento Incubadora Base de Conocimiento QA Durante la fase de incubación el grupo de QA de la organización sigue de cerca las evaluaciones realizadas por el grupo de calidad designado. A partir de estos estudios se decide la transición del proyecto de la base de incubación a la base de proyectos. Se evalúa la maduración del proyecto como propuesta. El grupo de aseguramiento de la calidad de la organización puede solicitar mas verificaciones concernientes a los diferentes aspectos del proyecto (objetivos de calidad, modelo de proceso a adoptar, adaptaciones de la especificación, etc. ). Previo a la transición de la etapa de incubación a la etapa de proyecto establecido es necesaria una consolidación inicial de los roles, con responsables en as diferentes áreas, así como definición de los métodos de comunicación de estado y avance del proyecto a grupo de calidad de la organización y a la alta directiva. Una vez incorporado el proyecto a la base de conocimientos de proyectos se comienza el trabajo específico de ingeniería de requerimientos, desarrollo, verificación, implantación, etc. Todas las áreas serán cubiertas por la gestión de la calidad en pro de la calidad del producto. Grupo de Calidad Designado

Asumiendo un proceso en Etapas Etapa Inicial Planificación Especificación Verificación por Pares Base de Conocimiento QA Asumiendo un proceso en etapas, presentamos a continuación como se realizan las diferentes interacciones entre los involucrados y cual es el rol principal del grupo de calidad designado y el grupo de calidad de la organización. El grupo de calidad de la organización delega responsabilidades al grupo de calidad designado. Se realizan revisiones eventuales para consultar el estado del proyecto. El grupo de calidad designado se encarga de verificar la incorporación del trabajo de cada uno de los involucrados a la base de conocimiento. (Ajustes a la especificación, Planificación, Verificaciones por pares a los ítem iniciales (documentos), Elaboración de frameworks para el desarrollo del producto o para su verificación, incorporación de nuevas tecnologías, etc.). El grupo de calidad designado (en conjunto con los directores de proyecto ) evalúan los objetivos de la etapa y determinan la finalización de la misma. Responsabilidad del grupo de calidad designado mantener la consistencia en la información que desprende la etapa para su posterior utilización. El proceso sigue los lineamientos del modelo y del proceso definido. También se realizan las actividades de calidad que se mencionan en los estándares en general. Objetivo principal asegurar la calidad del producto, controlar la calidad del proceso, validar las verificaciones realizadas sobres los diferentes entregables (completitud, lineamientos de estandarización, NO correctitud, es responsabilidad del grupo de verificación analizar la correctitud). Base de Conocimiento Proyecto Framework de Desarrollo y Verificación Grupo de Calidad Designado Objetivos de Calidad

Etapas de Elaboración y Construcción Verificación Automática Implementación Diseño Verificación Por Pares Base de Conocimiento QA Base de Conocimiento Proyecto En las etapas de elaboración y construcción el grupo de calidad designado se encarga (al igual que la etapa anterior) de la incorporación del trabajo generado a la base del conocimiento del proyecto. Los entregables de Diseño son verificados por revisiones por pares mientras que los entregables de implementación son verificados de forma automática. El grupo de calidad designado evalúa que la la verificación (por pares y automática) cumpla: Completitud Adaptación a los estándares de la organización. Los procesos son fuertemente basados en inspección automática, verificación unitaria y verificación de integración, en busca de código malicioso, errores de implementación, errores de funcionalidad. Estas herramientas no sustituyen al chequeo manual sino que brindan soporte mediante reportes para luego efectuar revisiones por parte del grupo de verificación. En todo momento el grupo de calidad designado debe poder brindar a la gerencia/gestión una visibilidad del estado del proyecto. Evalúa la calidad del proceso, a través de las mediciones conocidas. Evalúa las necesidades de cambio (evaluación de tecnologías, evaluación de procedimientos, asignación de tareas) Objetivos de Calidad Grupo de Calidad Designado Calidad de Uso

Etapa de Liberación Regresión Desarrollo Base de Conocimiento Proyecto Usuarios Calidad de Uso En la etapa de liberación el producto se pasa a manos de los usuarios para su evaluación. El conjunto de usuarios varia desde involucrados en el proyecto hasta personas ajenas al mismo que requieren de las funcionalidades del producto. El grupo de calidad designado en conjunto con el grupo de calidad de la organización establecen las políticas de liberación. Es decir se libera el producto conociendo los objetivos funcionales cumplidos (aquellos cuya verificación ha sido exhaustiva ) y los objetivos de calidad alcanzados (el nivel de calidad del producto liberado es acorde a los estándares de la organización). La calidad de uso toma importancia, se priorizan los comentarios y experiencia de utilización de los usuarios. El proceso de verificación continua en marcha. La detección y corrección de defectos cumple parte fundamental de esta etapa. El grupo de calidad designado en conjunto con el grupo de verificación elabora un proceso de verificación de regresión para complementar los esfuerzos de desarrolladores. El proceso de verificación de regresión es puesto en marcha con los usuarios. Se promociona la ejecución de la verificación de regresión. El grupo de calidad asignado analiza los resultados provenientes de los usuarios (uso, regresión) procesa los mismos e informa al grupo de calidad de la organización los puntos claves a mejorar. Verificación Base de Conocimiento QA Aseguramiento de Calidad (Org.) Grupo de Calidad Designado

Proyecto de Ingeniería de Software
Características Nombre del Producto: Unilab Desarrollado a distancia Equipo de desarrollo en Montevideo, Uruguay Cliente en Madrid, España Universidad Politécnica de Madrid

Proyecto de Ingeniería de Software (2)
Inconvenientes: Objetivos de Calidad no fueron contemplados exitosamente. Feedback de calidad del producto no adecuado. Poca retroalimentación. Puesta en Producción complicada. Servidor de Producción en España. Agenda de reuniones afectada por diferencia horaria.

Proyecto de Ingeniería de Software (3)
Conclusión Si bien se logró cumplir con el alcance establecido, los problemas de comunicación afectaron la calidad del proceso y del producto.

Preguntas ? ? ? ? ? ?

Desarrollo de Software a Distancia Gestión de Software 2006

Presentaciones similares

Presentación del tema: "Desarrollo de Software a Distancia Gestión de Software 2006"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

Desarrollo de Software a Distancia Gestión de Software 2006

Presentaciones similares

Presentación del tema: "Desarrollo de Software a Distancia Gestión de Software 2006"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback