Ingeniería de Requisitos en
Sistemas Complejos
Ferroviarios
Pedro Calle
Seminario
Gestión de Requisitos en Sistemas
Comple...
2
Índice
• ¿Qué es TechOnRails?
• Problemática sector ferroviario
• ¿Por qué Visure Requirements?
• Conclusiones
3
¿Qué es TechOnRails?
Compañía española enfocada a servicios
profesionales de ingeniería y desarrollo
software
4
Problemática Sector Ferroviario
• Proyectos de gran calado y duración
• Cumplimiento de normativa CENELEC 50128
• Gran v...
5
Un proyecto de señalización ferroviaria en cifras
• 20% análisis y desarrollo
• 80% pruebas y documentación
Modificacion...
6
Un proyecto de señalización ferroviaria en cifras
• Pruebas funcionales
• Pruebas no funcionales
• Documentación
– Requi...
7
Un proyecto de señalización ferroviaria en cifras
• >500 requisitos funcionales
• >1800 pruebas funcionales
• Interrelac...
8
¿Por qué Visure Requirements?
• Herramienta flexible  de proyectos
pequeños a grandes
• Mismo producto, pero funcionali...
9
Resultados obtenidos y conclusiones
• Poco tiempo para especificación del sistema
– Reutilización de componentes
– Integ...
9
Resultados obtenidos y conclusiones
• Poco tiempo para especificación del sistema
– Reutilización de componentes
– Integ...
Próxima SlideShare
Cargando en…5
×

Ingeniería de requisitos en sistemas complejos ferroviarios - Pedro Calle - TechOnRails

494 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
494
En SlideShare
0
De insertados
0
Número de insertados
2
Acciones
Compartido
0
Descargas
8
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.
  • Desde 2007 Colaboración con medianas y grandes empresas buscando la relación en el medio-largo plazo. Objetivo: socios tecnológicos A nivel de valores, buscamos compromiso, profesionalidad, adaptabilidad y, lo que hoy en día es la base del negocio: confianza. Para ello, debemos estar siempre al tanto de las herramientas tecnológicas que nos hagan ser más versátiles. Objetivo: Desarrollar una relación de confianza a largo plazo con nuestros clientes y colaboradores, con un crecimiento sostenible, una aportación tecnológica continua, bajo un criterio de satisfacción, rentabilidad y eficacia Especialización en entornos complejos Análisis de procesos + Herramientas de productividad. Ejemplo de aplicación de IRQA
  • No son proyecto -> son programas. Puestas en servicio a 2-3 años vista CENELEC 50128. SW para sistemas de control y protección del ferrocarril Pocos requisitos de alto nivel, que desembocan en cientos de requisitos Alto grado de integración con sistemas de otros fabricantes Gran volumen de documentación Auditoría externa para poder homologar el sistema
  • Pruebas funcionales y no funcionales Documentación: Requisitos de sistema Especificación funcional del sistema Especificación de pruebas Documento de resultado de pruebas Pruebas no funcionales Pruebas estáticas Pruebas dinámicas (coberturas asociadas a métricas) Boundary analysis
  • Pruebas funcionales y no funcionales Documentación: Requisitos de sistema Especificación funcional del sistema Especificación de pruebas Documento de resultado de pruebas Pruebas no funcionales Pruebas estáticas Pruebas dinámicas (coberturas asociadas a métricas) Boundary analysis
  • Flexibilidad. No se puede dedicar el tiempo de un consultor o del Jefe de Proyecto en especificar el entorno del sistema durante mucho tiempo Misma metodología que en el desarrollo software: POO  Reutilización de objetos (explicar el concepto). Se puede poner el ejemplo de un proyecto Driverless y un unmanned. Sólo por el hecho de las puertas, hay que rehacer todo el proyecto a nivel de requisitos y sistema Se puede especificar la norma como requisitos de obligado cumplimiento, y con un nivel alto de criticidad. De esta manera, se puede trazar contra los requisitos de sistema No sólo requisitos, sino que se pueden definir los casos de uso, diagramas de interacción, y diagramas de componentes. También escenarios de pruebas
  • Ingeniería de requisitos en sistemas complejos ferroviarios - Pedro Calle - TechOnRails

    1. 1. Ingeniería de Requisitos en Sistemas Complejos Ferroviarios Pedro Calle Seminario Gestión de Requisitos en Sistemas Complejos. ¿Estás preparad@?
    2. 2. 2 Índice • ¿Qué es TechOnRails? • Problemática sector ferroviario • ¿Por qué Visure Requirements? • Conclusiones
    3. 3. 3 ¿Qué es TechOnRails? Compañía española enfocada a servicios profesionales de ingeniería y desarrollo software
    4. 4. 4 Problemática Sector Ferroviario • Proyectos de gran calado y duración • Cumplimiento de normativa CENELEC 50128 • Gran volumen de documentación a controlar • Auditoría externa para poner los equipos en producción
    5. 5. 5 Un proyecto de señalización ferroviaria en cifras • 20% análisis y desarrollo • 80% pruebas y documentación Modificaciones detectadas  Crecimiento exponencial a medida que avanza el proyecto (funcionales y no funcionales)
    6. 6. 6 Un proyecto de señalización ferroviaria en cifras • Pruebas funcionales • Pruebas no funcionales • Documentación – Requisitos de sistema – Especificación funcional del sistema – Especificación de pruebas – Documento de resultado de pruebas – Etc…
    7. 7. 7 Un proyecto de señalización ferroviaria en cifras • >500 requisitos funcionales • >1800 pruebas funcionales • Interrelación entre requisitos de n a n • Inmanejable con herramientas de oficina que todos tenemos en mente ¡Necesidad de una herramienta que ayude a la gestión de requisitos!
    8. 8. 8 ¿Por qué Visure Requirements? • Herramienta flexible  de proyectos pequeños a grandes • Mismo producto, pero funcionalidades diferentes para distintos operadores  Reutilización de objetos de unos proyectos a otros • Posibilidad de integrar la norma, y ver cómo afecta • Trazabilidad desde requisitos a pruebas
    9. 9. 9 Resultados obtenidos y conclusiones • Poco tiempo para especificación del sistema – Reutilización de componentes – Integración con SW de terceros • Versatilidad y facilidad para el uso de la herramienta • Generación de informes muy sencilla • Reducción de costes vs otras herramientas • Se cubren necesidades más allá de REQ • Desarrollo continuo de la herramienta  posibilidad de adaptaciones a medida
    10. 10. 9 Resultados obtenidos y conclusiones • Poco tiempo para especificación del sistema – Reutilización de componentes – Integración con SW de terceros • Versatilidad y facilidad para el uso de la herramienta • Generación de informes muy sencilla • Reducción de costes vs otras herramientas • Se cubren necesidades más allá de REQ • Desarrollo continuo de la herramienta  posibilidad de adaptaciones a medida

    ×