Experiencia en implantación de una metodología

Presentación del tema: "Experiencia en implantación de una metodología"— Transcripción de la presentación:

1 Experiencia en implantación de una metodología
José Manuel Portero García Universidad de Huelva

2 Índice Contexto Situación actual Metodología de trabajo Herramientas
Un día de trabajo Conclusiones

3 Contexto Objetivos: Comentar trabajo de un equipo desarrolladores, en la actualidad en la UHU, para que esta experiencia sea útil en un contexto profesional. Primera charla de una serie de charlas que profundizarán en cada uno de los aspectos de se presentan.

4 Contexto Colaboración entre The Distributed Group (TDG) y una empresa del tejido industrial andaluz para: Aumentar el nivel de calidad de la empresa. Crear una EBT. · Esta charla se desarrolla en el contexto de colaboración entre el grupo de investigación TDG y una empresa del tejido industrial andaluz” · Se desea aumentar el nivel de calidad de la empresa, aventajando a otras del mismo sector en este aspecto.” · La EBT a formar tendría las siguientes características: - Modelo de la fábrica de software. - Sede en Huelva y disponible a finales de 2009 - Especialización en desarrollo de software de calidad. · Actualmente el grupo incipiente trabaja en implantar un método de trabajo que se heredará al finalizarlo.

5 Contexto El TDG está interesado en definir su metodología de trabajo para sus desarrollos software. Killer application. Implementación de extractores de información. Verificadores de información. … El grupo de investigación está interesado en definir una metodología ágil, adaptada a proyectos de investigación para el desarrollo software que lleva a cabo. - El objetivo de la siguiente charla es ir contando esta metodología del TDG que se va a alimentar de las experiencias que se va a contar en esta presentación.

6 Situación actual

7 Situación de partida En las empresas y grupos de investigación se desarrollan diversos tipos de proyectos. Diferentes tipos de clientes con requisitos muy diversos. - Diferentes líneas de negocio. Aplicaciones con requisitos muy diferentes. Una metodología poco apropiada puede no adaptarse a todos estos tipos de proyectos.

8 Problemas Los equipos de trabajo tienen un cierto nivel de independencia entre ellos. En cada grupo de trabajo, el jefe de proyecto tiene la última decisión sobre la estrategia a seguir. Los jefes de proyectos tienen que realizar un seguimiento manual de las actividades. Los equipos de trabajo tienen un cierto nivel de independencia entre ellos. Especialización en una línea de negocio diferente. Diferentes herramientas para el desarrollo de proyectos distintos. En cada grupo de trabajo, el jefe de proyecto tiene la última decisión sobre la estrategia a seguir. Diferentes metodologías dentro de la misma empresa. Adaptación de un nuevo desarrollador procedente de otro grupo de trabajo. Licencias software. Los jefes de proyectos tienen que realizar un seguimiento manual de las actividades. Es difícil realizar y seguir una planificación. Es muy costoso mantener la lista de tareas actualizada y conocer el estado de ellas. No se dispone de mecanismos que agilicen la comunicación entre integrantes del mismo equipo. La revisión del trabajo tiene que ser individual.

9 Problemas Los analistas y arquitectos no disponen de una documentación adecuada de los proyectos. Los desarrolladores no tienen un marco de desarrollo estándar. No hay definido un plan de pruebas ni de control de calidad, o bien este es básico e incompleto. Los analistas y arquitectos no disponen de una documentación adecuada de los proyectos. No se reutiliza apenas la información de proyectos anteriores. La falta de documentación en los problemas en desarrollo dificultan la comunicación entre los participantes. No hay una definición completa del problema y cae en los niveles últimos la toma de decisiones de diseño. Los desarrolladores no tienen un marco de desarrollo estándar. Coexistencia de equipos que desarrollan bajo diferentes sistemas operativos. Las versiones de las aplicaciones y sus componentes no siempre coinciden en todos los equipos. El programador, en última instancia, elige su aplicación favorita entre las que están disponibles.

10 Problemas Consecuencias
1.- Retrasos en los proyectos y aumento del coste del mismo. 2.- Prisas en el proyecto que reducen la calidad del software. 3.- Posible suspensión del proyecto. 4.- No se guarda un historial de los proyectos.

11 Excelencia operativa Solución
Estrategia de mejora de los procesos internos de trabajo a través del establecimiento de una metodología específica que permita lograr los objetivos de calidad y eficiencia en el desempeño diario. - Apoya las áreas de negocio, desarrollo y producción de los diferentes sectores de la empresa.

12 Excelencia Operativa Descansa en tres conceptos: Calidad
Eficiencia Productividad

13 Excelencia Operativa Ejes de la estrategia de mejora
CMMi ITIL OpenUP CMMi: Modelo de proceso que estructura, controla y mejora los procesos y productos. Obtener un nivel de madurez CMMi es obtener un reconocimiento local, nacional e internacional. ITIL: Marco de referencia para la gestión de los sistemas de producción, mantenimiento y gestión de garantías. OpenUP: Metodología UP.

14 4. Gestionado cuantitativamente
CMMi 5.Optimizado 4. Gestionado cuantitativamente 3. Definido 2. Gestionado 1.- En el nivel de madurez 1, los procesos son adhoc y caóticos. · Dependencia de héroes. · Se invierte demasiado dinero en los proyectos. · Se abandonan los procesos en momentos de crisis y no se repiten sus éxitos. 2.- En el nivel de madurez 2, los procesos disponen de gestión de requisitos y se planifican, ejecutan, miden y controlan los procesos. · La disciplina garantiza el mantenimiento en momentos de estrés. · Se hace uso de los work products. 3.- En el nivel de madurez 3, los procesos están bien definidos y entendidos y se emplean estándares, procedimientos, herramientas y métodos. · La organización establece y mejora su proceso. · En nivel 2, los estándares, procesos, descripciones y procedimientos pueden ser muy diferentes en cada proyecto, mientras que en el nivel 3 se adaptan a cada proyecto. · En este nivel los procesos se describen de manera más rigurosa. 4.- En el nivel de madurez 4, la organización y los proyectos establecen objetivos cuantitativos para la calidad y la ejecución de procesos y los emplea como criterios en la gestión de procesos. · A nivel 4, la ejecución de procesos se controla mediante técnicas cuantitativas o estadísticas y es predecible. 5.- En el nivel de madurez 5, la organización mejora continuamente sus procesos basados en una comprensión cuantitativa de las causas comunes de variación inherentes en los procesos. · Se mejora continuamente el proceso, innovándolo y mejorando la tecnología. 1.Inicial

15 CMMi Para llegar a nivel 3: Decision Analysis and Resolution
Integrated Project Management Integrated Teaming Organizational Environment for Integration Organizational Process Definition Organizational Process Focus Organizational Training Product Integration Requirements Development Risk Management Technical Solution Validation Verification Transparencia finalmente omitida.

16 ITIL Marco de trabajo de las mejores prácticas destinadas a facilitar la entrega de servicios de tecnologías de la información. ITIL se compone de los siguientes procesos de base: Gestión de incidencias Gestión de problemas Gestión del cambio Gestión de despliegue Gestión de la configuración en producción

17 Metodología de trabajo

18 OpenUP Metodología ágil basada en UP.
- Es libre y adaptable a las necesidades de cada empresa. - Simplifica RUP eliminando algunas disciplinas y roles. - Se enfoca en mitigar los riesgos desde el principio y se centra en la arquitectura.

19 OpenUP Conceptos a tratar: Incremento. Iteración.
Ciclo de vida del proyecto. Entrega. Fases.

20 OpenUP Disciplinas: Gestión de proyecto Requisitos Arquitectura
Desarrollo Pruebas Gestión de proyecto: - Establecer un consenso con los stakeholders sobre las tareas más prioritarias. - Estimular la colaboración en el equipo. - Fomentar las pruebas continuas del software. - Contribuir a las creación de entorno de trabajo que maximice la productividad. - Mantener a todos los implicados en el proceso informados. - Proveer un mecanismo para la gestión de riesgos y adaptarse a los cambios. Requisitos: - Entender el problema a resolver. - Entender las necesidades del cliente. - Definir los requisitos funcionales. - Definir la frontera del sistema. - Identificar las interfaces externas del sistema. - Identificar las restricciones de la solución. - Proveer las bases para planificar las iteraciones. - Proveer las bases para estimar costes y planificar. Arquitectura: - Construir una arquitectura robusta para el sistema. Desarrollo: - Transformar los requisitos en el diseño del futuro sistema. - Adaptar el diseño a un entorno de implementación. - Construir el sistema de manera incremental. - Verificar que las unidades técnicas empleadas para construir el sistema funcionan como se ha especificado. Pruebas: - Comprobar que el sistema cumple los requisitos. - Medir el progreso en pequeños incrementos. - Identificar problemas con la solución. - Asegurar que los cambios en el sistema no introducirán nuevos defectos. - Acelerar el proceso facilitando el descubrimiento de problemas con requisitos, diseños e implementaciones tan pronto como sea posible.

21 OpenUP Roles: Stakeholder Gestor de proyecto Analista Arquitecto
Desarrollador Probador Cualquier rol - Stakeholder: · Interesado en la consecución del proyecto. - Gestor de proyecto: · Planifica el proyecto, coordina interacciones con los Stakeholders y mantiene al equipo centrado en conseguir los objetivos. - Analista: · Representa al cliente obteniendo información sobre lo que quiere. · Entiende el problema a resolver. · Captura y establece la prioridad de los requisitos. - Arquitecto: · Define la arquitectura software. · Realiza las decisiones técnicas que condicionan el diseño e implementación del sistema. - Desarrollador: · Responsable de desarrollar una parte del sistema, incluyendo diseñarlo para ajustarse a la arquitectura, prototipado de la interfaz de usuario para luego implementarlo, hacer pruebas unitarias e integrar los componentes. - Tester: · Realiza pruebas de esfuerzo.

22 OpenUP Work products: Gestión de proyecto Arquitectura Desarrollo
Lista de riesgos Cuaderno de arquitectura Lista de unidades de trabajo Desarrollo Implementación Plan de iteración Ejecutable Plan de proyecto Diseño Requisitos Pruebas de desarrollo Glosario Pruebas Visión Caso de prueba Requisitos del sistema Script de prueba Modelo de casos de uso Log de prueba Casos de uso

23 OpenUP Flujo de trabajo: Fase de inicio

24 Herramientas

25 Características Colaboran en la puesta en práctica de la metodología.
Citaremos aplicaciones libres que funcionan bajo Linux.

26 OSRMT Herramienta de gestión de requisitos.
Permite la trazabilidad de características, requisitos, diseño, implementación y pruebas. Modificado para la generación del documento de Visión, ERS y Test Case. Modos de funcionamiento. Base de datos.

27 OpenProj Herramienta de gestión de proyectos.
Clon de Microsoft Project.

28 Redmine Gestor de proyectos con interfaz web.
Múltiples capacidades y ampliable mediante plugins. Multiple projects support Flexible role based access control. Flexible issue tracking system Gantt chart and calendar News, documents & files management Feeds & notifications. Per project wiki Per project forums Simple time tracking functionality Custom fields for issues, projects and users SCM integration (SVN, CVS, Git, Mercurial, Bazaar and Darcs) Multiple LDAP authentication support User self-registration support Multilanguage support Multiple databases support

29 Bouml Herramienta de modelado UML 2.
Generación de código en C++, Java, Idl, Php y Python. Extensible mediante plugouts.

30 Eclipse Entorno de desarrollo multilenguaje.
Extensible con gran cantidad de plugins.

31 Un día de trabajo

32 Todos los roles Gestor de repositorio

33 Todos los roles Peticiones asignadas

34 Todos los roles Realizar una petición

35 Todos los roles Foro de consulta y discusión

36 Jefe de proyecto Revisar peticiones

37 Jefe de proyecto Nivel de realización de las tareas.

38 Jefe de proyecto Consulta del repositorio

39 Jefe de proyecto Planificación de tareas

40 Analista Gestión de requisitos.

41 Modelador Modelo de negocio. Diagrama de casos de uso.

42 Modelador Diagramas de clases / secuencia / colaboración.

43 Modelador Diagrama de despliegue

44 Modelador Generación de XMI para AndroMDA

45 Modelador Generación automática de documentos

46 Modelador Generación de clases de prueba.

47 Desarrollador Desarrollo en Java

48 Desarrollador Ver las tareas asignadas de redmine

49 Desarrollador Sincronización con el repositorio

50 Conclusiones

51 Conclusiones