IBM Software Group Sólo para uso interno de IBM y Asociados de Negocios IBM Ingeniería de...
-
Upload
peppi-herro -
Category
Documents
-
view
2 -
download
0
Transcript of IBM Software Group Sólo para uso interno de IBM y Asociados de Negocios IBM Ingeniería de...
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM
Ingeniería de Requisitos
Abril de 2009
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM2
Objetivos
Al finalizar esta actividad, los participantes deberán estar en capacidad de:
1. Describir algunos de los desafíos clave del desarrollo de productos en el sector industrial
2. Describir los desafíos de la ingeniería de requisitos
3. Describir en dónde encaja la ingeniería de requisitos dentro del proceso de desarrollo de producto
4. Describir por qué fallan los procesos de requisitos y las razones comunes por las que fallan los
productos
5. Describir los beneficios de un enfoque mejorado de la ingeniería de requisitos
6. Listar los componentes de una solución de ingeniería de requisitos
7. Describir las capacidades y beneficios clave de IBM® Rational ® DOORS ®, IBM Rational
Requirements Composer y IBM Rational Quality Manager como parte de la solución de Ingeniería
de Requisitos de IBM
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM3
Agenda
Tendencias en el Desarrollo y Entrega de Producto
Desafíos que Resultan de Procesos de Ingeniería de Requisitos Insuficientes
Buenas Prácticas para una Ingeniería de Requisitos Exitosa
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM4
Agenda
Tendencias en el Desarrollo y Entrega de Producto
Desafíos que Resultan de Procesos de Ingeniería de Requisitos Insuficientes
Buenas Prácticas para una Ingeniería de Requisitos Exitosa
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM5
66% de los CEOs
esperan que sus organizaciones sean inundadas
con cambios
Problemas de la fuerza laboral
Las Compañías están Enfrentado una Tasa de Cambio Sin ParaleloLa Innovación se Considera Clave para el Éxito
Fuente: IBM Global CEO Study, 2006
Competencia intensificada
Escalamiento de las expectativas de los
clientes
Cambios inesperados del mercado
Globalización
Avances tecnológicos
Preocupaciones por regulaciones
“Lucharemos nuestras batallas, no por la ruta inferior de la mercantilización, sino por la ruta superior de la innovación.” CEO de una de las Principales Compañías de Electrónicos y Entretenimiento
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM6
Electrónica
Aeroespacial y Defensa
35% de aumento del valor de la electrónica y el software dentro de los vehículos para el 2010
90% de la innovación se basa en la electrónica y el software incorporado
La necesidad de diferenciación de producto está generando un aumento de la cantidad de software en los productos
La necesidad de reducción de costos/mayor innovación está resultando en asociaciones de diseño a lo largo de los límites legales, tecnológicos y de seguridad
Sector Automotriz
La Competencia y las Exigencias de los Clientes están Fomentando Cambios
en el Desarrollo de Productos
Se han estado generando cambios a lo largo de toda la cadena de suministros - incluso los repuestos de los consumibles requieren ahora software y electrónica sofisticados
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM7
Aumento del enfoque en ingeniería de software
Rastreabilidad completa de los requisitos a lo largo del ciclo de vida del producto
Diseño holístico del sistema e interacción
3D CAD PDM enfocada en
BOM mecánica Mejora de
organización y procesos
2D CAD Gestión de datos
ad-hoc Sin cambios en
organización / procesos
Desarrollo de Producto
Diseño Asistido por Herramientas
Reingeniería
Innovación
El Panorama del Desarrollo de Producto está Evolucionando De Enfocarse en el Costo – a Enfocarse en la Innovación
Presente y Más Allá1980 - Presente1970 - 1980
Globalización de proveedores, fuerza de trabajo y mercados
Nueva tecnología para costos y tiempo reducidos y mayor flexibilidad
Mejora de la productividad mediante la automatización
Incentivadores de Negocios
Valor de Negocios
Rápida innovación donde el software es el principal diferenciador
Reducción de tiempo y de costos
Producción mejorada con mayor calidad
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM8
Agenda
Tendencias en el Desarrollo y Entrega de Producto
Desafíos que Resultan de Procesos de Ingeniería de Requisitos Insuficientes
Buenas Prácticas para una Ingeniería de Requisitos Exitosa
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM9
Electrónica
Aeroespacial y Defensa
La complejidad de los sistemas electrónicos conduce a problemas de calidad, retrasos en los proyectos y a costos por garantías
Retrasos y sobrecostos causados por errores encontrados durante las pruebas de integración de electrónica y software
Los costos por garantía se disparan cuando se encuentran errores después del release de producto
Serios problemas financieros y de calidad resultan de la necesidad de entender y gestionar mejor el cambio en todos los equipos
Sector Automotriz
Las Fallas en el Desarrollo de Producto Están Impactando el Resultado Final
Los costos por garantías en EE.UU. y Europa son del 2-3% de los ingresos
~50% de los costos por garantías están relacionados con la electrónica y el software incorporado
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM10
Agencia AeroespacialCohete prototipo de mil millones de US$ se auto-destruyó 40 segundos después del despegue, debido a un error del software de dirección a bordo
OEM AutomotrizUn error de software forzó un llamado a devolución de producto de 75 mil autos que se atascaban a altas velocidades
Fabricante de Equipos MédicosLlamaron a devolución 42 mil dispositivos desfibriladores debido a un software pobre
Las Fallas en Software y Productos Integrados Aún Abundan en las CompañíasA Pesar del Enfoque Permanente en PLM
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM11
Limpiaparabrisas Sensible a la Lluvia: Ejemplo de una Falla de Diseño de SistemaLos Sistemas Individuales Funcionaban, Pero Fallaron Cuando se Integraron
Los diagnósticos iniciales señalaron al software como el culpable de la falla
Los mecánicos no pudieron probar el comportamiento del software
Otros componentes (unidad de control electrónico, sensor y parabrisas) funcionaron normalmente cuando se probaron independientemente
La falla no fue de componentes individuales, sino de la interacción a nivel de sistema
Parabrisas suministrado por un proveedor local
Incompatible con el rango de operación del sensor
No se capturó el requisito para una adecuada calibración del sistema (p. ej., compatibilidad de sensor y de parabrisas)
Los autos se enviaron a los clientes con un sistema de limpiaparabrisas que no funcionaba
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM12
La Ingeniería de Requisitos Plantea Desafíos SignificativosA lo Largo del Ciclo de Vida del Producto y a lo Largo de los Dominios de la Ingeniería
Definición pobre de los requisitos de calidad – A menudo los requisitos se expresan pobremente– Los malos entendidos y las interpretaciones equivocadas suceden frecuentemente
Normalmente la Definición de Requisitos es ineficiente – Los requisitos son ubicuos e intensivos en trabajo– La recopilación de requisitos es compleja e involucra a bastantes interesados
La Gestión de Requisitos necesita de un compromiso significativo– Muchas actividades son manuales (p. ej. al análisis de cobertura y de dependencia)– Establecer y mantener la rastreabilidad puede consumir tiempo y ser propenso a errores– La gestión de cambios puede ser difícil en el contexto de los requisitos– A menudo los requisitos se validan tarde en el proceso, con vínculos al aseguramiento de la calidad
en la última parte
Proyecto, Configuración, Cambio, Herramientas de Medición y Documentación
Herramientas de Ingeniería de Requisitos
Herramientas de Análisis y
Diseño
ModelajeHerramientas
SimulaciónHerramientas
DesarrolloHerramientas
PruebasHerramientas
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM13
Ingeniería de Requisitos Debe Estar Mejor Integrada al Ciclo de Vida del Producto
Análisis de negocios: Arquitectura Corporativa, Gestión de Procesos de Negocios, Gestión de Producto, Gestión de Portafolio
Necesidades del Cliente
Definir Requisitos de
OperaciónDesarrollo de
ConceptoDefinición Preliminar
Compilación de Producto
/ Sistema
DefinirRequisitosde Sistema
Definición de Detalles
Entrega de Producto/ Sistema
Ejecución / Soporte /
Mantenimiento
Definición de Requisitos y Diseño de Arquitectura: Particionamiento de Sistema
Gestión de Programa y de Proyecto: Contabilidad de Costos, Planificación, Mediciones, Reportes, Gestión de Riesgo
Diseño e Implementación Detallados
Integración
Ingenieríade Software
IngenieríaElectrónica
IngenieríaMecánica
Verificación y Validación
Gestión de Cambios y de Configuración
Gestión de Requisitos
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM14
Ingeniería de Requisitos Debe Estar Mejor Integrada al Ciclo de Vida del Producto
Análisis de negocios: Arquitectura Corporativa, Gestión de Procesos de Negocios, Gestión de Producto, Gestión de Portafolio
Necesidades del Cliente
Definir Requisitos de
OperaciónDesarrollo de
ConceptoDefinición Preliminar
Compilación de Producto
/ Sistema
DefinirRequisitosde Sistema
Definición de Detalles
Entrega de Producto/ Sistema
Ejecución / Soporte /
Mantenimiento
Definición de Requisitos y Diseño de Arquitectura: Particionamiento de Sistema
Gestión de Programa y de Proyecto: Contabilidad de Costos, Planificación, Mediciones, Reportes, Gestión de Riesgo
Diseño e Implementación Detallados
Integración
Ingenieríade Software
IngenieríaElectrónica
IngenieríaMecánica
Verificación y Validación
Gestión de Cambios y de Configuración
Gestión de Requisitos
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM15
¿Por qué Fallan con Frecuencia los Procesos de Requisitos? Para Entregar los Resultados de Negocios Esperados
El proceso de Ingeniería de Requisitos no está totalmente definido ni se hace cumplir
Se utilizan múltiples herramientas de creación en el proceso de requisitos– Datos inconsistentes de requisitos
– Falta de una visión unificada de requisitos a medida que cambian y maduran a lo largo del ciclo de vida
Falta de comunicación a lo largo de los silos de negocios y funcionales– Los grupos individuales interactúan con requisitos
que son relevantes para sus procesos individuales
Los requisitos deben ser el hilo común que mantenga enfocados a todos los equipos en entregar valor a los clientes
A lo largo de todo el ciclo de desarrollo del producto A lo largo de todas las disciplinas de ingeniería – mecánica, electrónica y de software
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM16
No hay una diferenciación clara de los productos
Asignación de precio
Calidad del producto
Comercialización / promoción inadecuada
Llegada tarde al mercado/pérdida de demanda
El producto pasó por alto necesidades de los clientes
19%
23%
24%
26%
33%
46%
49%
Mejorar la comunicación y colaboración entre las disciplinas
Aumentar la visibilidad del estado de los requisitos
Aumentar la capacidad para predecir el comportamiento del sistema antes de las pruebas
Implementar o cambiar los procesos de desarrollo de nuevos productos para un enfoque multidisciplinario
Aumentar la visibilidad en tiempo real de la Lista de Materiales (BOM) del producto en todo el proceso de desarrollo
71%
46%
39%
43%
¿Qué Hay Detrás de Estas Fallas y del Aumento de los Costos?
Desafíos de Negocios
Oportunidades de Ingeniería
Aberdeen Group, System Design: New Product Development for Mechatronics, Michelle Boucher, David Houlihan, enero de 2008
Guía del CIO para el lanzamiento PERFECTO: Translating Innovation to Business Benefit, AMR Research, 2005
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM17
Agenda
Tendencias en el Desarrollo y Entrega de Producto
Desafíos que Resultan de Procesos de Ingeniería de Requisitos Insuficientes
Buenas Prácticas para una Ingeniería de Requisitos ExitosaDefinición de RequisitosGestión de RequisitosGestión de Calidad orientada por
Requisitos
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM18
Necesidades de Mercado
Nivel SuperiorEspecificación
FuncionalEspecificaciones
Especificaciones No Funcionales
Sistemas Requisitos
Especificaciones de Producto
Especificaciones de Producto
Estructural Requisitos
InterfazRequisitos
Un requisito es “una necesidad individual documentada, de lo que un producto o servicio particular debe ser o hacer”*– Los Requisitos Funcionales describen ciertos
comportamientos (o funciones) de “lo que el sistema deberá hacer”
– Los Requisitos No Funcionales describen qué tan bien deberán ejecutarse estos comportamientos (o funciones), p. ej., MTBF
Los requisitos guían el desarrollo completo de un sistema – Los requisitos se originan desde numerosas fuentes– Los requisitos deben ser cohesivos, completos,
consistentes, correctos, actualizados, factibles, no ambiguos y verificables
¿Qué Son los “Requisitos”?
*Fuente: Wikipedia 2008
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM19
Es Necesario un Enfoque en la Ingeniería de RequisitosPara Lograr Productos que Respondan Mejor a las Necesidades del Cliente
Cierra las brechas y enlaza el ciclo de vida de desarrollo del producto
– Cierra las brechas en la comunicación y el intercambio de datos entre el marketing, la ingeniería y el intercambio del producto
– Evita que ‘se pasen por alto’ dispositivos requeridos por el cliente
Reduce el trabajo adicional, demoras y costos por garantía; mejora la satisfacción del cliente
– Lleva a ingenieros mecánicos, eléctricos y electrónicos a ‘la misma página’ de los ingenieros de sistemas y de software
– Permite que los problemas se descubran mucho más rápido en el ciclo de vida del desarrollo, resultando en menores llamados a devolución
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM20
Es Necesario un Proceso de Requisitos Sistemáticos Para Entregar Productos que Sean Exitosos y Rentables
¿Estamos resolviendo el problema correcto?
¿Estamos resolviendo el problema correctamente?
Obtenga, capture, elabore, revise y discuta sobre los requisitos usando una variedad de técnicas y notaciones.
Ponga los requisitos en estructuras y relaciones usando atributos, enlaces y señales. Gestione el cambio usando análisis de impacto y de cobertura.
Haciendo Posible que Expertos en Negocios y en Tecnología Colaboren en los Requisitos
Definición de Requisitos
Gestión deRequisitos
Conceptualice
Analice
Establezca Prioridades
Comprenda
Analice
Inspire
Definición de Requisitos +Gestión de Requisitos = Ingeniería de Requisitos
Consulte las notas del ponentepara más información
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM21
Solución de Ingeniería de Requisitos de IBMPara Programas, Proyectos, Productos, Sistemas y Sistemas-de-Sistemas
Llevando a todos a la misma página– Incluye proveedores y sub-contratistas
Alcance de la gestión, además de evaluación y control del impacto del cambio Asegurando rastreabilidad de punta a punta – ¡una característica clave de un buen proceso
de AR!– Desde ideas, definición de características, especificaciones de producto y modelos...
– Hasta implementación, pruebas y mantenimiento de elementos mecánicos, eléctricos/electrónicos y software incorporado
Asegurando la conformidad con los acuerdos contractuales Demostrando cumplimiento de las regulaciones
Solución de Ingeniería de Requisitos de IBMCaptura • Análisis de Compensación • Validación • Gestión de Cambios • Rastreabilidad • Análisis de Impacto • Reportes y Mediciones • Monitoreo
Análisis de Negocios Análisis e Implementación de Sistemas/Productos
Prueba y MantenimientoAnálisisIdeas Implementación
Definición de Requisitos Gestión de Requisitos
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM22
Buenas Prácticas de la Ingeniería de Requisitos
Requisitos de ingeniería:− Desde el comienzo del ciclo de vida de producto y sistema− A través de cada fase del desarrollo − A lo largo de todas las disciplinas en mecánica, electrónica y software
Asegurar la rastreabilidad a lo largo de todos los niveles de requisitos
Madurar de un entorno aislado hacia uno colaborativo
Invertir el mismo enfoque y rigor en los requisitos de ingeniería que en la gestión de una Lista de Materiales mecánica
Integrar estrechamente la Ingeniería de Requisitos con la Gestión de Cambios, Productos y Portafolio y el Aseguramiento de la Calidad
Mejores compañías en su clase...
••
IBM Requirements Engineering SolutionCapture • Trade-off Analysis • Validation • Change Management • Traceability • Impact Analysis • Reporting & Metrics • Monitoring
Business Analysis Systems/Product Analysis & Implementation
Test & MaintenanceAnalysisIdeas Implementation
Requirements Definition Requirements Management
IBM Requirements Engineering SolutionCapture • Trade-off Analysis • Validation • Change Management • Traceability • Impact Analysis • Reporting & Metrics • Monitoring
Business Analysis Systems/Product Analysis & Implementation
Test & MaintenanceAnalysisIdeas Implementation
Requirements Definition Requirements Management
Consulte las notas del ponente para más información
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM23
Agenda
Tendencias en el Desarrollo y Entrega de Producto
Desafíos que Resultan de Procesos de Ingeniería de Requisitos Insuficientes
Buenas Prácticas para una Ingeniería de Requisitos ExitosaDefinición de RequisitosGestión de RequisitosGestión de Calidad orientada por
Requisitos
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM24
Todo Comienza con el Proceso Correcto de Definición de RequisitosDefina los Requisitos mediante un Enfoque Colaborativo e Iterativo
Colabore e itere con las partes interesadas – Fomente el diálogo en torno a limitaciones
y compensaciones– Establezca prioridades y gestione cambios – Logre un mutuo entendimiento sobre los
requisitos– Elabore para conocimiento de soluciones
Defina alcance y límites – Para el problema y para la solución sugerida– Usando visualizaciones y escenarios
Identifique los riesgos de la solución
Ventas
Clientes Proveedores
AsociadosTendencias de la Industria
Regulaciones
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM25
¿Cuáles son los ‘Requisitos’ para Definir Exitosamente los Requisitos?
Acuerdo entre todas las partes interesadas sobre el proceso para definir los requisitos Herramientas capaces de capturar percepciones, conocimiento y comunicación Repositorio Central
– Persiste todos los requisitos y datos relacionados tales como discusiones y comentarios
– Permitiendo acceso a todas las partes involucradas
Infraestructura de TI que permite la colaboración– Colaboración interna y externa
Soporte de diferentes formatos adecuados para personasde negocios y técnicos
– Texto, gráficos, tablas, diagramas
Capacidad para hacer cumplir un flujo de trabajo definido – Incluyendo aprobaciones, acreditaciones, etc.
Glosarios Compartidos– Reducen la ambigüedad en cuanto a terminología
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM26
La Definición Efectiva de Requisitos se Basa en la ColaboraciónPara Juntar Múltiples Puntos de Vista Dispares
Uso de Texto enriquecido, imágenes,y enlaces para capturar y
organizar información estructurada y no
estructurada
Servidor de Colaboración
Colaboración en tiempo real
usando discusiones
tipo Wiki, para alcanzar
rápidamente el fin de sesión
Construya Modelos de Caso de Uso y dé más detalles sobre procesos,
actores y actividades
Captura del propósito actual de un estado futuro
con Diagramas de Procesos de Negocios
Eliminación de la ambigüedad en terminología de
negocios y tecnología con
Glosarios Compartidos
Visualice la experiencia del
usuario con Bosquejos y
Guiones Gráficos de Interfaz de
Usuario
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM27
Servidor de Colaboración
Comparta el trabajo instantáneamente Usuarios / equipos / autorizaciones Conexión entre todos los artefactos Asignación de VersionesRational
DOORS
Rico Entorno de Creación Revisión Web y Aprobación
Ofrecimiento basado en Jazz™ y enfocado en colaboración de equipo
Colaboración mejorada entre interesados de negocios y equipos de proyecto
Lleva más pronto al proceso al equipo de desarrollo de sistemas
Bosquejo de Procesos
Interfaz de Usuario de Bosquejos y Guiones Gráficos
Glosarios
Casos de Uso
Interfaz estilo wiki Categorice / Etiquete Comente Revise / Apruebe
Integración Visio Requisitos de Texto Enriquecido
Rational Requirements Composer Definición de Requisitos y Colaboración Basada en Jazz
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM28
Agenda
Tendencias en el Desarrollo y Entrega de Producto
Desafíos que Resultan de Procesos de Ingeniería de Requisitos Insuficientes
Buenas Prácticas para una Ingeniería de Requisitos ExitosaDefinición de RequisitosGestión de RequisitosGestión de Calidad orientada por
Requisitos
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM29
Descomponga los requisitos en jerarquías– Desde arquitectura de alto nivel hasta diseño de
bajo nivel– Desde el sistema completo hasta las disciplinas
mecánica, de hardware y de software
Gestione las relaciones entre requisitos– De un nivel hacia otro y entre ellos
Agregue atributos a los requisitos– Autor, Historial, Prioridades, Riesgos, etc.
Haga visibles los requisitos a lo largo de todo el ciclo de vida– Proporcione acceso a los requisitos
a todos los participantes en el proceso
Mantenga la visibilidad y la rastreabilidad de los requisitos a lo largo de todo el proceso
Necesidades de Mercado
EspecificaciónDe Nivel Superior
EspecificacionesFuncionales
Especificaciones No Funcionales
RequisitosDe Sistemas
Especificaciones de Producto
Especificaciones de Producto
RequisitosEstructurales
RequisitosDe Interfaz
La Buena Administración de Requisitos Se Basa en un Enfoque Estructurado
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM30
La rastreabilidad es la clave para el cumplimiento – Los requisitos iniciales serán descompuestos, lo cual crea relaciones de rastreabilidad– Otras relaciones también pueden rastrearse, tales como “consiste en”, “verifica”, etc. – Se debe hacer cumplir la rastreabilidad con el fin de asegurar la consistencia y que todo esté
completo
La rastreabilidad desde los requisitos del cliente y a través del desarrollo del producto para pruebas y entrega, permite a las organizaciones:– Conocer cuáles requisitos se implementan y prueban y cuáles no– Gestionar y defenderse frente a la ampliación del alcance
1. 820.30(b) Design and Development Planning
Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.
The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.
The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.
2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a
device are appropriate and address the intended use of the device, including the needs of the userand patient.
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.
2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.2.10. Questions.
2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.
2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and
list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)
2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for
adequacy?
Comply with FDA Design Control Guidance GMP Regulation
1. Capture design and related information1.1. Input electronically formatted data1.2. Reference external information sources1.3. Reference external documentation
2. Store design and related information2.1. Identify and tag design information as unique “design elements”2.2. Organize design elements
2.2.1. Organize by Design Control Guidance Element2.2.2. Organize by inter-relationships
2.3. Ensure all design elements are available2.3.1. Store design elements by Design Control Guidance Element2.3.2. Store design elements and their historical values
3. Manage all user needs3.1. Identify the source of the user need3.2. Identify all user types (groups)3.3. Identify the customer (s)3.4. Profile the expected patients3.5. State the intended use of the product (family)3.6. Capture the acceptance criteria for each user need
4. Manage design input requirements4.1. Identify the source of the requirement4.2. Identify the associated user need4.3. Capture requirement description and attributes4.4. Capture acceptance criteria4.5. Assign responsibility for each requirement4.6. Manage incomplete requirements4.7. Manage ambiguous requirements4.8. Manage conflicting requirements4.9. Approve all requirements
5. Manage acceptance5.1. Ensure the acceptance of every user need5.2. Ensure the acceptance of every design input requirement5.3. Document the results of every user need acceptance test5.4. Document the results of every design input requirements test5.5. Make acceptance results available
6. Manage change6.1. Maintain history of design element changes
6.1.1. Make complete change history available6.1.2. Maintain history within and across any organizational procedure6.1.3. Maintain history within and across any project milestone6.1.4. Maintain history within and across any Design Control Guidance Elements
6.2. Capture frequency and nature of element changes6.2.1. Provide rationale for change6.2.2. Describe decisions made6.2.3. Identify approval authority for the change6.2.4. Capture date, time, and signature of approving authority
6.3. Identify impacted elements due to a change in another element6.3.1. Create backward traces to design elements within and across any organizational procedure6.3.2. Create backward traces to design elements within and across any project milestone
1.1. Identify impacted elements due to a change in another element Traceability Reports: consistency with driving design elements Impact Reports: other design elements affected Links to impacted design elements1.1.1. Create backward traces to design elements within and across any organizational
procedure Traceability Reports: Procedure Attribute
1.1.2. Create backward traces to design elements within and across any project milestone Traceability Reports: Milestone Attribute
1.1.3. Create backward traces to design elements within and across Design ControlGuidance Elements Traceability Reports: Linked design elements
1.1.4. Create forward impacts to design elements within and across any organizationalprocedure Impact Reports: Procedure Attribute
1.1.5. Create forward impacts to design elements within and across any project milestone Impact Reports: Milestone Attribute
1.1.6. Create forward impacts to design elements within and across Design ControlGuidance Elements Impact Reports: Linked design elements
1.2. Associate changed design elements with related elements Link Change Design Object with affected design element(s) Traceability Links and Reports from affected design element(s) Impact Links and Reports from affected design element(s)1.2.1. Associate design element changes with decisions, rationale, and approval authority
information Change Decision Objects with following Attributes: Disposition Attribute Decision Attribute Rationale Attribute Owner Attribute Management Approval Attribute
1.2.2. Provide associations within and across any organizational procedure Change Design Object Traceability Link on Procedure Attribute Change Design Object Impacts Link on Procedure Attribute
1.2.3. Provide associations within and across any project milestone Change Design Object Traceability Link on Milestone Attribute Change Design Object Impacts Link on Milestone Attribute
1.2.4. Provide associations within and across Design Control Guidance Elements Change Design Object Traceability Link to traced design elements Change Design Object Impacts Link to linked design elements
1.3. Mange the change process Design Change Module Design Change Reports Object History Object History Reports Versions Baselines
1. 820.30(b) Design and Development Planning
Each manufacturer shall establish and maintain plans that describe or reference the design and developmentactivities and define responsibility for implementation.
The plans shall identify and describe the interfaces with different groups or activities that provide, or resultin, input to the design and development process.
The plans shall be reviewed as design and development evolves.The plans shall be updated as design and development evolves.The plans shall be approved as design and development evolves.
2. 820.30(c) Design Input2.1. Each manufacturer shall establish procedures to ensure that the design requirements relating to a
device are appropriate and address the intended use of the device, including the needs of the userand patient.
2.2. Each manufacturer shall maintain procedures to ensure that the design requirements relating to adevice are appropriate and address the intended use of the device, including the needs of the userand patient.
2.3. The procedures shall include a mechanism for addressing incomplete requirements.2.4. The procedures shall include a mechanism for addressing ambiguous requirements.2.5. The procedures shall include a mechanism for addressing conflicting requirements.2.6. The design input requirements shall be documented by a designated individual(s).2.7. The design input requirements shall be reviewed by a designated individual(s).2.8. The design input requirements shall be approved by a designated individual(s).2.9. The approval, including the date and signature of the individual(s) approving the requirements,
shall be documented.2.10. Questions.
2.10.1. Summarize the manufacturer's written procedure(s) for identification and control ofdesign input.
2.10.2. From what sources are design inputs sought?2.10.3. Do design input procedures cover the relevant aspects, such as: (Mark all that apply and
list additional aspects.)2.10.3.1. intended use2.10.3.2. user/patient/clinical2.10.3.3. performance characteristics2.10.3.4. safety2.10.3.5. limits and tolerances2.10.3.6. risk analysis2.10.3.7. toxicity and biocompatibility2.10.3.8. electromagnetic compatibility (EMC)2.10.3.9. compatibility with accessories/auxiliary devices2.10.3.10. compatibility with the environment of intended use2.10.3.11. human factors2.10.3.12. physical/chemical characteristics2.10.3.13. labeling/packaging2.10.3.14. reliability2.10.3.15. statutory and regulatory requirements2.10.3.16. voluntary standards2.10.3.17. manufacturing processes2.10.3.18. sterility2.10.3.19. MDRs/complaints/failures and other historical data2.10.3.20. design history files (DHFs)
2.10.4. For the specific design covered, how were the design input requirements identified?2.10.5. For the specific design covered, how were the design input requirements reviewed for
adequacy?
Requisitos del Usuario
Requisitos Técnicos Casos de PruebaDiseño
La Gestión de Requisitos Debe Proporcionar Rastreabilidad del Ciclo de VidaDesde la Idea Hasta el Final del Ciclo
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM31
Consulte los atributos para encontrar propiedades específicas
– “¿Cuántos requisitos están listados como de alto riesgo?” Use los reportes de rastreabilidad para verificar
dependencias– Antes de que se confirmen los cambios
Encuentre enlaces “extraviados”– “¿Cuáles requisitos detallados no están relacionados con
un requisito de usuario de nivel superior?” Análisis de cobertura
– “¿Qué requisito de nivel superior no tiene requisitos de nivel inferior?”
Análisis de impacto– “¿Qué requisitos de nivel inferior son afectados si cambia
un requisito de nivel superior?” Mantenga la rastreabilidad
– Para cada incremento, si usted desarrolla incrementalmente con fases concurrentes
– Para cada variante, si usted maneja variantes y líneas de producto
La Buena Gestión de Requisitos Permite un Análisis Profundo
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM32
El Desarrollo de Sistemas Orientado por Modelo Mejora la Ingeniería de RequisitosVinculando Requisitos a Modelos Gráficos
“Las Mejores [compañías] en Su Clase reconocen que es crítico cumplir con los requisitos de diseño para llegar al producto final deseado… ellas planean el diseño a nivel de sistema y luego atan estos requisitos a cada aspecto del diseño.”
“En la práctica, lo que esto implica no es simplemente asegurar que los requisitos estén anticipados correctamente, sino manejarlos a lo largo de todo el ciclo de vida del diseño.”
Aberdeen Group, System Design: New Product Development for Mechatronics, Michelle Boucher, David Houlihan, enero de 2008
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM33
Requisitos del Usuario Requisitos Técnicos Casos de PruebaDiseño
ContextoRequisitosNavegador
Validación visual de punta a punta en una sola vista
Grabando los Requisitos dentro del Contexto
Visualizaciones combinadas de documento y hoja de cálculo
Interfaces simples e intuitivas para una fácil adopción
Historial y líneas de bases
Resuelve el problema correcto porque los requisitos están visibles todo el tiempo
Entrada y resultado desde/hacia varios formatos comunes
Rational DOORSGestione Todos los Requisitos A lo Largo del Ciclo de Vida y de las Disciplinas
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM34
Rational DOORS Ofrece un Rico Conjunto de Dispositivos ComprobadosPermitiendo una Fácil Adaptación de la Gestión de Requisitos
Rastreabilidad mediante vinculación con arrastrar y soltar – Enlace de documento a documento
o dentro de un documento– “Vinculación” automática para rastreabilidad
de arriba a abajo, desde los requisitos hasta el código
Escalable para proyectos grandes con muchos usuarios
Espacio para Discusiones DOORS que permite procesos de revisión
Acceso Web DOORS como una forma alternativa para acceder a sus datos
Un número virtualmente ilimitado de atributos, en una vista tipo hoja de cálculo
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM35
Rational DOORS está Estrechamente Integrado con Rational Rhapsody
Rational Rhapsody® y Rational DOORS ofrecen Ingeniería de Requisitos y de Sistemas Orientadas por Modelo
– Los modelos facilitan la rastreabilidad de requisitos y de sistemas y la validación temprana del diseño; captura los problemas de forma más temprana en el ciclo de vida para reducir el costo de los errores
– Soporte completo UML 2.1 y SysML
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM36
1. Los requisitos se enlazan con las órdenes de implementación
2. Las órdenes de implementación se enlazan con las tareas de ingeniería
3. Las tareas de ingeniería se enlazan con los artefactos gestionados
2) Rational Change™ o Rational ClearQuest®
3) Rational Synergy™ o Rational ClearCase
Artefactos Gestionados
Órdenes de Implementación Tareas de
Ingeniería
1) Rational DOORS
Gestión de Cambios, Historial y Líneas de Base
Rational DOORS Permite una Implementación Orientada por RequisitosVinculando Requisitos a Configuraciones y Conjuntos de Cambios
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM37
Agenda
Tendencias en el Desarrollo y Entrega de Producto
Desafíos que Resultan de Procesos de Ingeniería de Requisitos Insuficientes
Buenas Prácticas para una Ingeniería de Requisitos ExitosaDefinición de RequisitosGestión de RequisitosGestión de Calidad orientada por
Requisitos
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM38
La Gestión de Calidad Inicia con la Ingeniería de Requisitos La Gestión de Calidad Necesita Fuertes Vínculos con los Requisitos
Los requisitos son la materia prima para todas las especificaciones de calidad y para las pruebas
– Un Requisito Funcional define “Lo Que” el objeto de prueba debe hacer
– Un Requisito No Funcional define “Qué Tan Bien” debe hacerlo el objeto de prueba
Requisitosde interesado
Especificacionesde interesado
Diseñodel sistema
Especificacionesde Aceptación
Integración y pruebas de Unidad
Satisface Satisface
Pruebasde Aceptación
Pru
ebas
Pru
eb
as
Pru
eb
as
Gestión de Calidad vinculada a la Gestión de Requisitos– Incorpora los requisitos a planes de calidad y de pruebas– Relaciona casos de prueba, suites de prueba, ejecuciones de prueba y
resultados de prueba con los requisitos– Muestra cuáles requisitos son comprobados y cuáles no – Proporciona rastreabilidad entre y dentro de jerarquías de requisitos y de
pruebas
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM39
Mejore la Gestión de la Calidad Con un Enfoque en Colaboración, Automatización y Reportes
Colabore ReporteAutomatice
Soporta casos de prueba orientados por requisitos y la definición de suites de prueba
Ejecuta y evalúa pruebas de forma iterativa y temprana, manual o automáticamente
Genera reportes de prueba
Permite ejecución host y objetivo
Define claramente roles
y responsabilidades en la Gestión de Calidad
Crea y actualiza dinámicamente los planes de calidad y pruebas
Comparte activos parala gestión de la calidad y de los requisitos
Comunica el estado de los proyectos eficientemente
Mide el avance
Proporciona tasas de cobertura incluyendo la cobertura de requisitos
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM40
Rational Requirements
Composer Rational
Quality Manager
Procesos de negocios
Bosquejos y Guiones Gráficos
Casos de uso
Texto Enriquecido
Ingeniería de RequisitosIngeniería de Requisitos
Identifique y gestione requisitos a lo largo de su ciclo de vida
Alinee la colaboración de equipo en torno a objetivos y resultados de negocios
Rational DOORS
Gestión de Calidad Orientada por Requisitos Integra la Gestión de Calidad y la Ingeniería de Requisitos
*) *)
Planeación y configuración de la calidad más tempranas
Requisitos vinculados con los planes de calidad
Ejecución de pruebas más rápida Criterios de aceptación de objetivo Cobertura de pruebas de requisitos
*2do trimestre de 2009 *2do trimestre de 2009
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM41
Capture problemas de
calidad temprano, con
colaboración de ciclo de vida
Tome decisiones con
confianza con reportes sin
esfuerzo
Coordinación entre participantes y equipos Menos reuniones, menos trabajo adicional
usando un plan de pruebas dinámico Flujo de trabajo de proceso
automatizado Reduce las tareas intensivas en trabajo,
mejora el tiempo del ciclo
Mejora del proceso en curso Historial y tendencias de versión
dentro y a lo largo de los proyectos Gestión proactiva de riesgos y toma de decisiones
Reportes automatizados, filtrados y con prioridad asignada
IBM Rational Quality Manager
CONTINUOUS test plan participate
AUTOMATED context GOVERNANCEuse case distributed access dashboardssynchronize EASY HANDOFF trace LABUTILIZATION functional PERFORMANCEsecurity compliance
Rational Quality ManagerEntregando Innovación Directamente en las Manos de los Profesionales de la Calidad
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM42
Solución de Ingeniería de Requisitos de IBM En Palabras de los Clientes
Rational DOORS
Rational Quality Manager
Rational Requirements Composer
“ DOORS mejora la comunicación del equipo de desarrollo, lo cual ayuda a cumplir con los requisitos del cliente, más rápido y con mayor precisión.”
Fabricante de Partes Automotrices
“ Vemos buenas oportunidades para mejorar nuestros proyectos de TI con un excelente retorno de la inversión en el Requirements Composer”
Banco
“Pienso que… ahora las organizaciones tienen más opciones… No están obligadas a usar HP si no funciona bien en su entorno de desarrollo… Y con la buena integración con el sistema de control de versiones, mi opinión es que actualmente ellos [Rational] tienen una oferta de prueba mejor integrada que la de sus competidores.”
Compañía de Servicios de TI
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM43
¿Por qué IBM para Ingeniería de Requisitos?
“DOORS nos permite planear, ejecutar y realizar seguimiento del progreso de las prácticas que hemos mejorado para nuestros miembros... DOORS nos ayuda a proporcionar un buen ejemplo de buenas prácticas en la ingeniería de sistemas.“
Pat Hale, Presidente electo, Consejo Internacional de Ingeniería de Sistemas
(INCOSE)
Business Wire, 15 de mayo de 2007
“DOORS (Telelogic) ofrece la mejor cobertura de nuestra lista de
requisitos. Se destaca en nuestras cuatro dimensiones de evaluación.
DOORS demuestra fortalezas en la captura, enlace y análisis de los
requisitos durante todo su ciclo de vida.”
Yphise
Desarrollo Ágil Orientado por Requisitos,Yphise,
Marzo de 2008
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM44
IBM Ofrece las Mejores Soluciones en su Clase para Ingeniería de Requisitos
Aporte de Herramientas de Ingeniería de Requisitos– A lo largo de las disciplinas de ingeniería– Con base en Rational DOORS – Enriquecido con ofrecimientos basados en Jazz– Mejorado con integraciones y capacidades para gestión de configuración y de
cambios
Servicios de Ingeniería de Requisitos y Soporte Adicional– Servicios de Mejora de Procesos, incluyendo evaluaciones, consultoría, educación y
tutorías – Fuerte liderazgo y extensiones de producto por parte de IBM Global Business
Services y Asociados IBM (p. ej., Buenas Prácticas de Línea de Producto de Ingeniería)
– Soporte de Estándares (p. ej., CMMI)
IBM Requirements Engineering SolutionCapture • Trade-off Analysis • Validation • Change Management • Traceability • Impact Analysis • Reporting & Metrics • Monitoring
Business Analysis Systems/Product Analysis & Implementation
Test & MaintenanceAnalysisIdeas Implementation
Requirements Definition Requirements Management
IBM Requirements Engineering SolutionCapture • Trade-off Analysis • Validation • Change Management • Traceability • Impact Analysis • Reporting & Metrics • Monitoring
Business Analysis Systems/Product Analysis & Implementation
Test & MaintenanceAnalysisIdeas Implementation
Requirements Definition Requirements Management
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM45
Puntos de Aprendizaje
Al finalizar esta actividad, los participantes deberán estar en capacidad de:
1. Describir algunos de los desafíos clave del desarrollo de productos en el sector industrial
2. Describir los desafíos de la ingeniería de requisitos
3. Describir en dónde encaja la ingeniería de requisitos dentro del proceso de desarrollo de
producto
4. Describir por qué fallan los procesos de requisitos y las razones comunes por las que fallan
los productos
5. Describir los beneficios de un enfoque mejorado de la ingeniería de requisitos
6. Listar los componentes de una solución de ingeniería de requisitos
7. Describir las capacidades clave y los beneficios de Rational DOORS, Rational Requirements
Composer y Rational Quality Manager como parte de la solución de Ingeniería de Requisitos
de IBM
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM46
IBM Software Group
Sólo para uso interno de IBM y Asociados de Negocios IBM47
Información de CopyrightIBM Latin America HQ One Alhambra Plaza Coral Gables, FL 33134 USA
La página de presentación de IBM puede encontrarse en: ibm.com
IBM, el logotipo IBM, ibm.com y Rational son marcas registradas de International Business Machines Corporation en Estados Unidos, otros países o ambos. Si estos y otros términos con marca registrada de IBM están identificados en su primera ocurrencia en esta información con el símbolo de marca registrada (® o ™), estos símbolos indican marcas registradas o marcas registradas de derecho consuetudinario en EE. UU. de propiedad de IBM en el momento que se publicó esa información. Dichas marcas registradas también pueden ser marcas registradas o marcas registradas de derecho consuetudinario en otros países. Una lista actualizada de marcas registradas de IBM está disponible en la Web en "Copyright and trademark information", en: ibm.com/legal/copytrade.shtml
Otros nombres de compañías, productos o servicios pueden ser marcas registradas o marcas de servicios de otros.
Las referencias en esta publicación a productos o servicios de IBM no implican que IBM pretende ponerlos a disposición en todos los países donde IBM opera.
La información contenida en este documento se facilita sólo para fines informativos y es provista "tal como está", sin garantías de ninguna clase, expresas o implícitas. Además, esta información se basa en los planes y en la estrategia actuales de IBM respecto a los productos, que pueden ser cambiados por IBM sin aviso. Sin limitación a lo mencionado arriba, todas las declaraciones respecto a los rumbos futuros o a la intención de IBM están sujetas a cambio o retractación sin aviso y representan solamente metas y objetivos. Nada de lo contenido en esta documentación tiene la intención o tendrá el efecto de generar ninguna garantía o declaración de IBM (o bien de sus proveedores o concedentes de licencias) o de cambiar los términos y condiciones del acuerdo de licencia referente al uso del software de IBM.
Los clientes de IBM son responsables de asegurar su propia conformidad con los requisitos de la ley. El cliente es el único responsable de obtener asesoría jurídica competente respecto a la identificación e interpretación de las leyes y requisitos normativos relevantes que puedan afectar la empresa del cliente y las actitudes que el cliente pueda tener que tomar para cumplir con dichas leyes.
Producido en los Estados Unidos de América
© Copyright IBM Corporation 2010Todos los Derechos Reservados