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


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


Agenda




IBM Software Group


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


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


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


Agenda




IBM Software Group


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


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


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


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


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


¿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


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


Agenda



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


Necesidades de Mercado

Nivel SuperiorEspecificación

FuncionalEspecificaciones

Especificaciones No Funcionales

Sistemas Requisitos

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


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


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


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


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





Consulte las notas del ponente para más información

IBM Software Group


Agenda




Requisitos

IBM Software Group


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


¿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


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


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


Agenda




Requisitos

IBM Software Group


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



RequisitosEstructurales

RequisitosDe Interfaz

La Buena Administración de Requisitos Se Basa en un Enfoque Estructurado

IBM Software Group


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


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


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


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


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


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


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


Agenda




Requisitos

IBM Software Group


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


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


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


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


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


¿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


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 Software Group


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


IBM Software Group


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

IBM Software Group Sólo para uso interno de IBM y Asociados de Negocios IBM Ingeniería de...

Documents

Transcript of IBM Software Group Sólo para uso interno de IBM y Asociados de Negocios IBM Ingeniería de...