16 Vector Software SFIC 2009

637 views
534 views

Published on

Presentación de Vector Software en el SFIC 2009

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
637
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

16 Vector Software SFIC 2009

  1. 1. Cómo trabajar con una Factoría de Software 24/09/2009 Javier Mazo Torres Desarrollo de Negocio
  2. 2. Contenidos <ul><li>Vector SF </li></ul><ul><li>Tipología de Trabajo </li></ul><ul><li>Servicio Factoría </li></ul><ul><li>Una metodología adecuada </li></ul><ul><li>¿Por qué Vector? </li></ul><ul><li>Cómo trabajamos </li></ul><ul><li>Mecanismos de control </li></ul><ul><li>Definición : Análisis </li></ul><ul><li>Definición : Diseño </li></ul><ul><li>Construcción, integración y entrega </li></ul><ul><li>Trazabilidad y gestión del cambio </li></ul><ul><li>Niveles de Servicio </li></ul>Índice
  3. 3. 01. Vector SF <ul><ul><ul><li>Vector es una compañía dedicada al desarrollo de soluciones avanzadas de software, en el entorno de nuevas tecnologías. </li></ul></ul></ul><ul><ul><ul><li>Nacimos en el 2002 con el objetivo de desarrollar una Red de Centros de Producción orientándonos al desarrollo y mantenimiento de soluciones de software complejas para empresas y organizaciones de diversos sectores. </li></ul></ul></ul><ul><ul><ul><li>Hoy somos una Software Factory de referencia, con 48 clientes de muy diversos sectores empresariales, 18 millones de ingresos y 350 empleados distribuidos entre nuestros 4 centros de producción. </li></ul></ul></ul>Centros de Producción de Software de Vector Software Factory Pozuelo de Alarcón Villanueva de la Cañada Albacete Córdoba
  4. 4. 01. Vector SF
  5. 5. 02. Tipología de trabajos <ul><ul><ul><li>Proyecto: Cuando disponemos de un conjunto de requisitos y un alcance cerrado que permite establecer un plan de trabajo. </li></ul></ul></ul><ul><ul><ul><ul><li>Elaboramos un plan de proyecto y un presupuesto </li></ul></ul></ul></ul><ul><ul><ul><ul><li>El cliente aprueba el plan </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Nos encargamos de la ejecución y el seguimiento </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Control mediante la metodología tradicional de gestión de proyectos </li></ul></ul></ul></ul><ul><li>Utilizamos el enfoque de gestión más adecuado </li></ul>
  6. 6. 02. Tipología de trabajos <ul><li>Utilizamos el enfoque de gestión más adecuado </li></ul><ul><ul><ul><li>Servicios (Soporte y Mantenimiento): Cuando no podemos anticipar y planificar las peticiones de trabajo </li></ul></ul></ul><ul><ul><ul><ul><li>Acordamos con el cliente una línea base de trabajo que garantiza un nivel de respuesta. </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Definimos y seguimos acuerdos de nivel de servicio </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Resolvemos las peticiones en función del orden de llegada y las prioridades. </li></ul></ul></ul></ul>
  7. 7. 03. Servicio factoría <ul><li>Trabajando siguiendo el siguiente esquema </li></ul><ul><ul><ul><li>Establecimiento del servicio: El cliente transfiere a Vector SF el conocimiento necesario para llevar a cabo el mantenimiento </li></ul></ul></ul><ul><ul><ul><li>Definimos e implantamos todo lo necesario para prestar el servicio: procedimientos, herramienta control, informes de seguimiento, niveles de servicio </li></ul></ul></ul>
  8. 8. 03. Servicio factoría <ul><li>Trabajando siguiendo el siguiente esquema </li></ul><ul><ul><ul><li>Circuito de solicitud y realización de peticiones. </li></ul></ul></ul>
  9. 9. 03. Servicio factoría <ul><li>Trabajando siguiendo el siguiente esquema </li></ul><ul><ul><ul><li>Seguimiento global del servicio, con las consiguientes revisiones del modelo y de las condiciones del mismo. </li></ul></ul></ul>
  10. 10. 04. Una metodología adecuada <ul><li>Trabajando sin método… </li></ul><ul><ul><ul><li>DESORDEN: ¿Por dónde empezamos? </li></ul></ul></ul><ul><ul><ul><li>DESCOORDINACIÓN: ¿Quién tiene que hacer cada cosa? ¿Encajarán las piezas al final? Y si no encajan, ¿qué hacemos? </li></ul></ul></ul><ul><ul><ul><li>ESTIMACIONES INCORRECTAS: No creo que lleguemos a tiempo… </li></ul></ul></ul><ul><ul><ul><li>OPACIDAD: No sabemos como va a ser el proyecto hasta el final… </li></ul></ul></ul>
  11. 11. 04. Una metodología adecuada <ul><li>Trabajando sin método … </li></ul><ul><ul><ul><li>BAJA CALIDAD: ¿Alguien se ha encargado de probar que la aplicación funciona? </li></ul></ul></ul><ul><ul><ul><li>NO HAY TRAZABILIDAD: ¿Qué es lo que ha fallado? ¿Cuándo? ¿Dónde? </li></ul></ul></ul><ul><ul><ul><li>VULNERABLE A LOS CAMBIOS: Si cambian algo, el proyecto se viene abajo. </li></ul></ul></ul><ul><ul><ul><li>IMPOSIBLE APRENDER: La próxima vez cometeremos los mismos errores </li></ul></ul></ul>
  12. 12. 04. Una metodología adecuada <ul><li>Utilizando una metodología </li></ul><ul><ul><ul><li>GESTIÓN DEL CAMBIO. Podemos gestionar los cambios en cualquier fase </li></ul></ul></ul><ul><ul><ul><li>TRAZABILIDAD. Siempre sabemos qué ha fallado, cuándo, dónde y qué supone para el proyecto </li></ul></ul></ul><ul><ul><ul><li>APRENDIZAJE. Reducimos de manera sensible la curva de aprendizaje de los profesionales que se incorporan al proyecto. </li></ul></ul></ul><ul><ul><ul><li>RAPIDEZ. Aceleramos el desarrollo mediante la reutilización de componentes. </li></ul></ul></ul><ul><ul><ul><li>MEJORA CONTINUA. El producto mejora en cada iteración. Cuantos más proyectos realizamos, lo hacemos mejor y más rápidamente. </li></ul></ul></ul>
  13. 13. 05. ¿Por qué Vector? <ul><li>Tenemos una metodología propia que garantiza </li></ul><ul><li>los estándares más altos de calidad </li></ul><ul><ul><ul><li>Estamos certificados en CMMI nivel 3, estándar de referencia mundial en la ingeniería de software, e ISO de calidad 9001 </li></ul></ul></ul><ul><ul><ul><li>Proporcionamos al cliente una fotografía clara del avance del proyecto en todas las fases </li></ul></ul></ul><ul><ul><ul><li>Nuestra metodología nos permite adaptarnos a los diferentes tipos de proyectos, sea cual sea el tamaño y la tecnología: Java, PHP, Punto Net, etc. </li></ul></ul></ul>
  14. 14. <ul><li>Definición: </li></ul>06. Cómo trabajamos <ul><li>Aplicamos nuestra metodología en 3 fases: </li></ul><ul><ul><ul><li>QUÉ HAY QUE HACER: Analizamos los requisitos, definimos los casos de uso, los casos de prueba y los componentes de presentación </li></ul></ul></ul><ul><ul><ul><li>CÓMO VAMOS A HACERLO: Diseñamos los componentes, la imagen gráfica y el prototipo en HTML </li></ul></ul></ul>
  15. 15. 06. Cómo trabajamos 3. Instalación: entregamos el producto final completamente probado <ul><li>2. Construcción: empezamos a programar </li></ul><ul><ul><ul><li>Desarrollamos el código </li></ul></ul></ul><ul><ul><ul><li>Integramos los diferentes elementos </li></ul></ul></ul><ul><ul><ul><li>Subsanamos los errores detectados en las pruebas </li></ul></ul></ul>
  16. 16. 06. Cómo trabajamos INSTALACIÓN
  17. 17. 07. Mecanismos de control <ul><li>Un profesional ajeno al proyecto, revisa el trabajo y certifica que todo es correcto: </li></ul><ul><li>Verifica que el producto satisface las especificaciones. </li></ul><ul><li>- Identifica cualquier desviación sobre los estándares. </li></ul><ul><li>- Detecta oportunidades de mejora. </li></ul><ul><li>- Promueve el intercambio de técnicas y la formación de los participantes </li></ul><ul><li>Para reducir los riesgos al mínimo, aplicamos </li></ul><ul><li>mecanismos de control a lo largo de todo el proceso. </li></ul><ul><ul><ul><li>Peer Review de requisitos, análisis, diseño y construcción </li></ul></ul></ul>
  18. 18. 07. Mecanismos de control Nos permite congelar la imagen del proyecto (crear una línea base) en los puntos clave: inicio, análisis, diseño, testing y entrega. Siempre sabemos qué hemos hecho y cómo. El conocimiento está ordenado y estandarizado: los profesionales pueden realizar su trabajo de forma más eficiente, y el cliente obtiene informes periódicos del avance del proyecto. <ul><ul><ul><li>Peer Review de requisitos, análisis, diseño y construcción </li></ul></ul></ul><ul><ul><ul><li>Gestión de configuración </li></ul></ul></ul>
  19. 19. 07. Mecanismos de control INSTALACIÓN
  20. 20. 08. Definición : Análisis <ul><li>El primer input y nexo de unión con el cliente es la recepción de los requerimientos. </li></ul><ul><ul><ul><li>Realización del diseño funcional: </li></ul></ul></ul>
  21. 24. 08. Definición : Análisis <ul><li>A partir de los requisitos del cliente, </li></ul><ul><li>definimos los casos de uso. </li></ul><ul><ul><ul><li>REQUISITO: El usuario autorizado debe tener acceso a la aplicación. </li></ul></ul></ul><ul><ul><ul><li>CASOS DE USO: El usuario introduce el usuario y password, y pulsa el botón “Aceptar”. Si está registrado en la base de datos, la aplicación le permite acceder. En caso contrario, le envía un mensaje de error. </li></ul></ul></ul>
  22. 25. 08. Definición : Análisis <ul><li>A partir de los casos de uso definimos los casos </li></ul><ul><li>de prueba y los componentes de presentación </li></ul><ul><ul><ul><li>CASOS DE PRUEBA </li></ul></ul></ul><ul><li>1. El usuario registrado introduce sus datos. Comprobar que la base de datos funciona correctamente. </li></ul><ul><li>2. El usuario no está registrado e introduce los datos. Comprobar que la aplicación le muestra un mensaje de error. </li></ul>
  23. 27. 08. Definición : Análisis <ul><li>Componentes de presentación </li></ul><ul><li>Lo importante no es el aspecto, sino la distribución y el flujo de elementos. </li></ul><ul><li>Utilizamos la herramienta Axure. </li></ul>
  24. 32. 08. Definición : Análisis <ul><li>Gestión de Requisitos: Existe una correspondencia múltiple </li></ul><ul><li>Gestionamos de manera </li></ul><ul><li>eficaz estas inter-relaciones. </li></ul><ul><li>. </li></ul><ul><li>Utilizamos herramientas especializadas </li></ul><ul><li>(IRQA) para gestionar los cambios sin </li></ul><ul><li>poner en riesgo el proyecto </li></ul><ul><ul><ul><li>SI ALGO CAMBIA O SE DETECTA UN ERROR EN UNA PARTE, TODO EL CONJUNTO SE VE AFECTADO. </li></ul></ul></ul>Un caso de uso Varios requisitos Varios casos de prueba Un requisito Varios casos de uso Varios casos de prueba
  25. 33. INSTALACIÓN 08. Definición : Análisis
  26. 34. 09. Definición : Diseño <ul><li>A partir de los casos de uso diseñamos los </li></ul><ul><li>componentes: definimos las clases, la estructura de la </li></ul><ul><li>base de datos, etc. </li></ul><ul><li>A partir de los componentes de presentación, </li></ul><ul><li>diseñamos una propuesta gráfica y una maqueta HTML. </li></ul>
  27. 35. 09. Definición : Diseño INSTALACIÓN
  28. 36. 10. Construcción, integración y entrega <ul><li>Iniciamos el desarrollo de los paquetes de código </li></ul><ul><li>Subsanamos los errores detectados mediante las pruebas </li></ul><ul><li>Desarrollamos e integramos el código con todas las garantías </li></ul><ul><ul><ul><li>CONTROL DE VERSIONES </li></ul></ul></ul><ul><ul><ul><li>INTEGRACIÓN CONTINUA </li></ul></ul></ul><ul><ul><ul><li>CONTROL DE CALIDAD </li></ul></ul></ul><ul><ul><ul><li>TEST UNITARIOS </li></ul></ul></ul>
  29. 37. <ul><li>Herramienta de pruebas (Testlink) </li></ul><ul><ul><li>Casos de pruebas </li></ul></ul><ul><ul><ul><li>Aplicación web que registra el detalle y el estado de cada prueba realizada en cada versión de software </li></ul></ul></ul><ul><ul><ul><li>Monitoriza en tiempo real el avance de las pruebas y su estado. </li></ul></ul></ul><ul><ul><ul><li>Se integra con la aplicación de seguimiento de incidencias, informando los errores encontrados y su estado </li></ul></ul></ul><ul><ul><li>Informes </li></ul></ul><ul><ul><ul><li>Se generan informes para cada fin de ciclo </li></ul></ul></ul><ul><ul><ul><li>Métricas que ayudan a la toma rápida de decisiones </li></ul></ul></ul>05. Herramientas
  30. 38. <ul><li>Integramos el producto final, perfectamente probado, en la plataforma tecnológica del cliente </li></ul>10. Construcción, integración y entrega
  31. 39. INSTALACIÓN 10. Construcción, integración y entrega
  32. 40. 11. Trazabilidad y gestión del cambio <ul><li>Trazabilidad: podemos recuperar una “foto” </li></ul><ul><li>(línea base) exacta de la situación en cualquier </li></ul><ul><li>instante del proyecto. </li></ul><ul><li>Así sabemos qué ha fallado, cuándo, dónde y por qué, y somos capaces </li></ul><ul><li>de medir el impacto de los cambios. </li></ul>
  33. 41. <ul><ul><ul><li>Detectamos de inmediato cualquier error, y lo rastreamos. Siempre sabemos qué ha fallado, dónde, cuándo y por qué. </li></ul></ul></ul><ul><ul><ul><li>Gestionamos los cambios de manera rápida y eficaz: podemos medir la incidencia real de un cambio en todo el proyecto, y ejecutarlo sin perjudicar al desarrollo final. </li></ul></ul></ul><ul><ul><ul><li>Controlamos en todo momento las inter-relaciones entre requisitos, casos de uso, casos de prueba, componentes de presentación y paquetes de código. </li></ul></ul></ul><ul><ul><ul><li>Nuestra herramienta de gestión documental </li></ul></ul></ul><ul><ul><ul><li>(DMS) nos permite mantener la información </li></ul></ul></ul><ul><ul><ul><li>siempre actualizada y accesible para el cliente. </li></ul></ul></ul>“ La detección de un error o la introducción de un cambio en un punto concreto implica realizar modificaciones en diferentes partes y fases del proyecto. Con nuestra metodología, podemos controlarlo” 11. Trazabilidad y gestión del cambio
  34. 42. 11. Trazabilidad y gestión del cambio <ul><ul><ul><li>Análisis del impacto y viabilidad de la petición </li></ul></ul></ul><ul><ul><ul><li>Estudiar petición </li></ul></ul></ul><ul><ul><ul><li>Identificar urgencia y criticidad </li></ul></ul></ul><ul><ul><ul><li>Analizar impacto </li></ul></ul></ul><ul><ul><ul><li>Estimar </li></ul></ul></ul>y generar documento de petición de cambio que incluye: <ul><ul><ul><li>descripción del cambio </li></ul></ul></ul><ul><ul><ul><li>análisis realizado, incluyendo el impacto y la viabilidad de la petición </li></ul></ul></ul><ul><ul><ul><li>supuestos y consideraciones realizadas durante el análisis. </li></ul></ul></ul><ul><ul><ul><li>Planificación y estimación propuestas para acometer el cambio. </li></ul></ul></ul><ul><ul><ul><li>diseño técnico </li></ul></ul></ul>
  35. 43. INSTALACIÓN 11. Trazabilidad y gestión del cambio
  36. 44. 12. Niveles de Servicio <ul><li>Medición inicial </li></ul><ul><ul><ul><li>Obtenemos datos reales de calidad, volumen y servicio </li></ul></ul></ul><ul><ul><ul><li>Establecemos los niveles de servicio requeridos </li></ul></ul></ul><ul><ul><ul><li>Dimensionamos el equipo de trabajo de acuerdo al volumen y los niveles de servicio </li></ul></ul></ul><ul><li>Seguimiento periódico de indicadores </li></ul><ul><li>Revisión periódica de los niveles acordados </li></ul>
  37. 45. 12. Niveles de Servicio <ul><li>Servicio basado en la estimación de plazos de desarrollo y la ejecución real </li></ul><ul><ul><ul><li>Plazo de estimación de las peticiones: </li></ul></ul></ul><ul><ul><ul><ul><li>Tiempos medios de estimación de peticiones </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Porcentaje de peticiones estimadas en plazo </li></ul></ul></ul></ul><ul><ul><ul><li>Plazo de entrega/aceptación del desarrollo vs plazo estimado </li></ul></ul></ul><ul><ul><ul><ul><li>Tiempo medio de desviación de la entrega/aceptación </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Porcentaje de peticiones entregadas/aceptadas en plazo </li></ul></ul></ul></ul><ul><ul><ul><li>Calidad del producto entregado: </li></ul></ul></ul><ul><ul><ul><ul><li>Porcentaje de no conformidades sobre los casos de prueba </li></ul></ul></ul></ul>
  38. 46. INSTALACIÓN 12. Niveles de Servicio MEDICIÓN DE NIVELES DE SERVICIO
  39. 47. Vector Software Factory Parque empresarial La Finca Paseo del Club Deportivo, 1 - Bloque 11 28223 Pozuelo de Alarcón Madrid ____________________________ http://www.vectorsf.com Javier Mazo Torres Desarrollo de Negocio Tel.: (+34) 615 904 349 [email_address]

×